s12一些硬件资料

平生不得志

第一章 App结构
A1000 S12的App通过控制相关的电路为交换机提供各种服务, 其中最主要的一个就是呼叫处理功能, 并带有一系列特别的服务(缩位地址、三方通话、详细计费等等), 除此之外, App还为管理者实行操作、管理、维护任务提供便利。


　　整个A1000 S12App按照功能的共性分成一系列的子系统(subsystem)，子系统进一步又分成一系列的域(area), 而域最后又分成一组App模块(module)。这种分类致力于把App和硬件的发展变化分离，采用虚拟机(Virtual Machine)概念来获得一种用户界面友好、灵活、易于测试的App(即模块化结构)。



　

- 操作系统(Operating System)



- 数据库(Database)



- 呼叫处理(Call Handling)



- 电话支援(Telephone Support)



- 维护(Maintenance)



- 管理(Administration)



每个子系统又分为一系列的App域(SW area)：



* 操作系统和数据库包含下列App域:



- 操作系统核(Operating System Nucleus)



- 网络处理器(Network Handler)



- 输入/输出处理(Input/Output)



- 人机App(Man Machine SW)



- 装载和初始化(Load and Initialiation)



- 时钟, 信号音和日历



- 数据库管理系统



* 电话支援子系统由下列域组成:



- 电话设备和信令调整



- 信令处理



- 计费



- 远端用户单元(RSU)



- CCITT七号信令消息发送



* 呼叫处理由下列域组成:



- 呼叫处理和特服



- 呼叫服务



* 维护子系统包含下列域:



- 维护App



- 状态和告警App



- 用户线和中继测试App



- 测试信号分析器(TSA)和测试处理单元(TAU)App



* 管理子系统包含:



- 管理App(话务量和性能测量)



- 扩容处理


App模块在App结构里处于最低级。App域由相互独立的App模块组成，这些模块称为FMM(Finite Message Machines，有限消息机)和SSM(System SupportMachines，系统支撑机)。FMM之间采用标准的数据结构----消息(Message)进行通信。从FMM到SSM通过过程调用(Procedure Call), 从SSM到FMM通过消息来通信。



　　所有这些App模块分布在不同的硬件模块中。当然这种分布不是任意的，每个模块只含有工作所需的那部分App。



　　支援App－－操作系统核、网络处理器、数据库App等等分布在交换机里的所有模块中。



1 虚拟机(Virtual Machine)和设备处理器(Device Handler)





正如前面所提及的, S12系统目标之一就是获得App与硬件设备技术发展的完全独立。所以，如果由于技术的发展，一部分交换机硬件电路需要改进，那么对相应App的修改将减少到最小程度。为了实现这一目标，每种不同的交换机硬件电路由一个单独的App模块直接控制，这个单独的App模块就是设备处理器(DH--Device Handler)。设备处理器控制对设备的驱动。

　　比如：为了控制用户电路，在一定时间里有几个不同的交换机App在工作：



　　　　－　呼叫处理，用于检测摘机，发送拔号音，检测拔号脉冲等



　　　　－　维护App，实行预防性的或校正性的维护以及清除故障



　　　　－　管理App，在操作员请求下使电路退出服务



　　如果所有这些App都要直接访问设备，那么所有的程序设计者必须对电路内部结构有相当深度的了解，而且硬件的改变必然导致对程序的修改。



　　如果设计一种App作为仅有的被允许访问用户电路的程序(即设备处理器)，当其它App需要对电路工作时，它们将发送一个命令给设备处理器，由设备处理器来控制硬件实行具体的命令。



　　不同App对设备处理器的请求实际上是象征性的命令，不会随着设备技术的改变而变化，比如：占据(Seizure), 禁止(Disable)等命令。设备处理器把这些命令转换成能被设备识别的信号。这样，任何App都能访问用户电路而不必知道它的内部结构。用户电路和它相应的设备处理器就构成了虚拟机(Virtual Machine)。虚拟机这个概念允许硬件的发展不对其余的系统App产生任何影响。



　　从这个概念扩展开来，一个虚拟机就是一台真正的机器再加上为机器的使用者提供抽象操作的程序。后面大家将看到这个概念应用在操作系统和数据库中的例子。



2 FMM(有限消息机)





* 定义和特性



一个FMM就是一个基本的App结构功能块, 有着下列特点：



　　－它只能通过消息(message)与别的FMM通信



－从外面来看，一个FMM象是一个"黑盒子", 就是说：系统的其余部分不了解它的内部结构。FMM的功能行为由它所发送和接收的消息组唯一确定



　　－FMM可以处在几种不同状态中的任意一种并且状态之间的转移是允许的。对于每一种状态，一组有限的消息被定义，每当收到一个消息，FMM会产生并发送消息, 而且它所处的状态也会相应改变



* FSM(Finite State Machine)：有限状态机



由定义大家知道一个FMM可处在几种状态。FMM可发送一个或多个消息, 一旦接收到一个消息，FMM可从一种状态转移到另一种状态。由这种状态转变机制引入有限状态机(FSM)的概念。



　 为了正确理解这个概念, 大家以图3-1-3所示的例子来说明。从图中可看到这个FMM可接收消息A、B和C, 并且进而发送消息D和E, FMM的功能行为则由其接收和发送消息的顺序完全确定。在大家这个例子中顺序是：这个FMM要发送消息D。它必须先接收消息A或C紧接着接收消息B。为了发送消息E, 它必须在接收消息A之前先接收消息B。



　　 这个FMM可处在三种状态。图3-1-3描述了这个FMM工作的方式。这三种状态是：



- INIT: 这种状态表示FMM正等待消息A, B或C, 如果它接收到消息B, 状态转变为B-REC状态, 如果它接收到消息C, 则转变为C-REC状态



- B-REC: 这个状态表示FMM已接收到消息B, 并且正等待消息A, 当消息A到达后, FMM将发送消息E并回到INIT(初始)状态



　



　



　



　　　　　　　　　　图3-1-2 FMM (有限消息机):黑盒子








- C-REC: FMM已接收到消息C并且正等待消息B, 当消息B到达, FMM发送消息D并且回到INIT(初始)状态



* FMM类型



在讨论FMM不同类型之前, 大家先定义一个与FMM实行(工作)相关的非常重要的术语: 进程(process)。一个FMM由进程定义和进程数据两部分组成, 进程定义(process definition)即程序代码, 而进程数据就是进程工作所需的数据。进程定义使用相关进程数据实行程序的过程，就是进程。



　　下面大家通过一些实例来说明不同类型的FMM。首先，让大家看一下负责字冠分析的FMM。当运行时，这个FMM将判别本次呼叫的目的地, 是本局还是出局。当收到以消息的形式发来的请求时，这个FMM就利用数据区里的数据(进程数据)起动程序(进程定义)的实行。在实行结束时，该FMM发送一个消息并释放数据区。如果一个新的消息到达，请求分析字冠，这个FMM的进程定义将再次实行, 相同的数据区再次被使用。这种类型的FMM需要一个单一的数据区。由于在任何给定的时刻仅有一个进程处于活跃状态，故把这类FMM称为单进程FMM (Monoprocess FMM)。




第二个例子, 负责呼叫建立的FMM。当一次呼叫建立时，一个进程被创建，它把本次呼叫所需的全部消息存贮在一个数据区里。这个FMM将在一段时间里处理一个用户；如果在这段时间里另外一个用户起动了一次呼叫，这个FMM必须为该呼叫存贮数据，但不能用同一个数据区，因为此数据区已被第一次呼叫所占用。因此这个FMM若要同时处理多个呼叫, 就必须创建独立的多个数据区(每次呼叫一个)。





　 以这种方式实现的FMM称为多进程FMM(Multiprocess FMM)。在上述例子中，每次新的请求都要创建一个独立的数据区。当一次请求完成以后，所占用的数据区相应被释放。在这个FMM中负责创建和释放数据区的部分称为监控部分(Supervisory part)而且有着自已的数据区。负责实行FMM实际功能的部分称作应用部分(Application Part)。



　　监控部分的实行就是监控进程，而应用部分在一个数据区上的实行就是应用进程。这意味着多进程FMM总是含有一个监控进程和数目可变的多个应用进程。






到目前为止, 大家已知道两种类型的FMM----单进程和多进程, 每一种类型都有着自己特定结构和操作方式。一个单进程FMM在一段时间里只能处理一个实行请求。除此之外，还有一种特殊类型的FMM, 它只有一个进程但能同时处理多个请求。



　　大家以一个扫描用户电路的FMM为例来说明。这些用户电路数目是固定的并且是预先知道的；再有扫描必须持续实行。在这些条件下，每个电路都需要一个数据区但数据区的数目是固定的。



　　如果这个FMM用多进程来实现, 那么它的监控部分必须在初始化时为每个电路创建一个应用进程。由于扫描必须持续进行，所有这些进程将一直存在。



　　这种解决办法看来不是最聪明的，也不是最有效的。另一个办法就是采用单进程FMM, 它为每个设备保留一个数据区, 也就是一个单一进程控制固定数目的一组电路。以这种方式实现的FMM叫做单进程多设备(Monoprocess Multidevice)FMM。






还有一类FMM, 它们不需要定期实行, 或者需占用相当多的存贮空间。具有这些特性的FMM不能长久驻留在CE的内存中, 所以称为覆盖FMM(OFMM----Overlay FMM)。它们通常存贮在系统磁盘上，只有在需要时才被装载进CE的内存中。此时FMM的程序代码和数据被放入CE内存中一个特殊区域----"覆盖区"中。



3 消息(message)





* 定义和特性



在上一节中大家已经知道, FMM之间只能通过标准化的信息结构----消息来通信。



　　消息具有如下特性：



　　－当一个消息要发送时，信息将被放进一个64字节的数据结构----消息缓冲区(message buffer)中。每个CE中都有一组消息缓冲区。



－消息缓冲区由两部分组成：头(header)和体(body)。消息头用于把消息送往目标所在的FMM, 它占用16个字节。在消息头中主要包含下列信息：一个编号(消息标识), 它唯一标识这个消息；一个优先级；消息类型等(图3-1-7所示)。消息体分为两部分，第一部分是文本，即实际的信息，占用40个字节。第二部分是为操作系统保留的，占用8 个字节。



　　－消息的结构是"脱机"定义的, 并被所有的FMM熟知。当一个FMM要发送一个消息时, 它必须首先申请一个可用的消息缓冲区。操作系统将搜寻一个可用缓冲区并把含有消息缓冲区起始地址的指针送给发出请求的FMM。这个FMM利用指针把消息拷贝到消息缓冲区中。同样地，一个指针将被送给目标所在的FMM, 用于读取消息中的信息

消息头



. 信息长度



. 消息标识



. 优先级



. 类型



. 目标



. 源



消息体





文本(最多40字节)



保留字



* 消息类型



到目前为止, 大家把消息作为FMM之间的通信方式, 但是，实际上它们是用于FMM进程之间的通信。消息总是通过"消息缓冲区"来发送/接收。根据源进程是否知道目标进程，大家把消息分为两种主要类型：



　　＋基本消息(Basic Message)：这种类型的消息由一个FMM( 进程 )发往另一个FMM(进程)。当消息发送时实际的目标并没有指定。操作系统将负责确定目标进程的位置。比如，处理呼叫建立的FMM, 当一次新的呼叫建立时, 还没有一个活跃的处理它的进程；所以检测呼叫建立的FMM发给上述FMM的第一个消息, 是一个没有指定目标的基本消息



　　＋定向消息(Directed Message): 这种类型的消息由一个进程发往一个已知的目标进程。在上面例子中，当呼叫建立继续时，源进程已经知道目标所在的进程。所以接下来源进程以定向消息把呼叫事件发往目标进程



接收和发送消息有两条规则：



　　(1) 监控进程可发送/接收基本消息和定向消息



(2) 应用进程只能接收定向消息, 但可发送基本消息和定向消息



上述规则既适用于多进程FMM的监控部分, 也适用于单进程FMM。所以，单进程FMM仅有的进程也称作监控进程。




* 应用进程的创建



多进程FMM创建应用进程的步骤：



　　(1) 一个进程发送一个基本消息给一个FMM的监控进程。监控进程收到基本消息后，决定创建一个应用进程以处理消息中包含的请求。



　　(2) 监控进程通过操作系统的服务来创建这个应用进程。这个新进程从创建起被赋予一个标识，这个标识当然是被监控进程了解的。



　　(3) 由于监控进程已经知道所创应用进程的标识, 从这时起它将发送一个定向消息给该应用进程。这个消息中包含监控进程从基本消息中接收的全部信息。



　　(4) 应用进程从收到的定向消息中读取信息并开始实行。实行后的结果或者是发送一个基本消息给别的进程，或者是发送一个定向消息给发送第一个基本消息的进程。从现在起，源进程通过定向消息与这个应用进程通信(注意：应用进程只能接收定向消息)。



　　(5) 当应用进程完成任务后, 它将通知操作系统, 分配给它的资源(进程数据)也被释放。