基于分布式航电系统的系统管理功能设计

刘 宇， 金 鑫， 魏学杭

(航空工业第一飞机设计研究院,a.航电系统设计所; b.民机总体工程部,西安 710000)

0 引言

随着航空电子技术的发展，航电系统设计在工程应用中逐步向分布式系统架构靠拢。分布式架构通过在物理位置上分布综合化的模块，用容错通信系统连接，实现功能的综合。分布式架构的优点是降低系统集成的复杂度，系统规模可变，故障隔离，减少了重量，缩小了体积。

分布式系统以网络为中心，形成信号和数据资源池，使信息共享从数据向信号处理推进，信息可以传输到任一个处理模块，构建分布式处理系统，能够提升系统的计算处理能力和容错重构能力，有利于功能综合、系统重构，提高系统的性能、可靠性和安全性。

目前，国内关于系统管理的功能设计主要集中在模块级别，并没有立足于航电系统功能的层面，从应用实例的角度对系统的资源进行调度，也没有实际可行的系统管理运行机制。文献[1-5]重点在于对系统管理的重构机制进行描述，不具有实际的可操作性；文献[6-8]从故障信息处理的角度介绍了健康管理的实现原理；文献[9-10]描述了系统管理的基本概念，并没有具体的应用场景实例。在工程实现中，系统管理重构的实现，是通过穷举所有可能发生的重构策略，切换不同的策略配置表实现的，重构策略都是基于固定配置，策略并不灵活，系统管理无法根据系统实际情况进行调整，而且传统的接口控制文件(Interface Control Document,ICD)设计中，消息与资源的关系密切，通常定义为设备到设备的传输数据，所以在枚举策略的同时，也要维护大量的ICD更改。当系统中增加或减少设备时，应用组件及ICD都需要进行变更，带来大量工作。

1 航电系统架构与系统管理功能

结合FACE架构的结构特点，抽象出分布式航电系统的3层架构，分为应用层、中间层和资源层，如图1所示。

图1 航电系统层次结构Fig.1 Hierarchy of avionics system

本文提出系统管理功能驻留于中间层，能够对航电系统中的分布式资源进行管理，它服务于航电系统的功能，解除了硬件资源、网络层与应用间的耦合关系，实现可配置性。通过配置能够更改应用软件驻留的资源位置；在不影响应用软件和ICD设计的同时，能够灵活配置组件的余度以及组件的备份关系和数据使用的供需关系。通过对资源的管理，最大程度地减少应用、网络通信以及资源故障对系统带来的影响。

2 系统管理设计

2.1 功能组件

在系统功能设计中，设计者根据系统功能定义功能组件。系统中存在com1功能组件、com2功能组件与com3功能组件，如图2所示。

图2 组件间的消息协作时序图Fig.2 Message collaboration sequence between components

3个组件之间的消息交互关系是com2组件发送消息到com1组件，com1组件处理后发送给com3组件，图2描述了组件间的协作关系。

2.2 服务角色

从系统安全性、可靠性等角度出发，系统中可以灵活设置功能组件的余度关系、热备份关系和冷备份关系，余度关系定义为多服务角色，热备份和冷备份定义为单个服务角色。系统中设计了不同组件的余度关系，如图3所示。

图3 服务角色Fig.3 Service role

图3中,com1组件为三余度设计，即三余度设计整体才能完成系统分配的功能。com1组件的冗余设计定义为服务角色A(com1A)，服务角色B(com1B)，服务角色C(com1C)；com2组件为双余度设计，其冗余设计定义为服务角色A(com2A)，服务角色B(com2B)；com3为单余度设计，服务角色为com3A。

结合图2组件间的协作关系确定组件服务角色之间的消息传输。此时，系统设计者需要明确冗余组件是否需要与其他组件之间进行全联通式的通信。本文中，com2B服务角色并没有与com1组件的所有服务角色进行数据传输，如图4所示，这种联通方式是由系统设计者从安全性等多方面综合考虑后确定的。

图4 角色连接Fig.4 Role connection

2.3 组件实例

为保证系统的任务可靠性，实现系统重构，每个服务角色的承担者为一个或多个组件实例。组件实例如图5所示。

图5 组件实例图Fig.5 Diagram of component instance

图5中，com1组件有com1_I_1,com1_I_2,com1_I_3,com1_I_4这4个组件实例，com2组件有com2_I_1,com2_I_2,com2_I_3这3个组件实例，com3组件有com3_I_1,com3_I_2这2个组件实例。实际参与系统运行的组件实例，被赋予系统服务角色，该角色对应1个组件实例，当发生故障时，该角色当前的组件实例被其他组件实例替代。

系统中出于可用性考虑，在运行时，只要资源允许，尽量保证足够的组件及组件实例参与系统运行，实际能提供组件实例个数应大于系统需要的个数，当发生故障时，系统能够用多余的实例代替发生故障的组件实例，以满足系统可用性要求。

系统正常运行时，服务角色com1A，com1B，com1C分别由组件实例com1_I_1,com1_I_2，com1_I_3承担，当com1_I_1发生故障时，com1_I_4则替代com1_I_1承担com1A的服务角色。图4中,与com1A服务角色建立通信的应用不用更改通信关系，仍然与com1A通信，但实际承担com1A服务角色的组件实例已经由com1_I_1变为com1_I_4。

根据图4中角色之间的通信关系以及图5的组件实例关系，建立了图6所示的组件实例之间的消息图。

图6 消息生成逻辑Fig.6 Message generation logic

2.4 资源节点

资源节点是航电系统硬件资源的统称，每个资源节点都可以运行一个或多个组件实例。考虑通信关系以及共模影响的约束，进行组件实例在资源节点上的部署。

资源节点resource node4作为备份的资源，驻留备份的组件实例com1_I_4和com2_I_3，如图7所示。

图7 系统架构关系Fig.7 System architecture relationship

2.5 系统管理代理

在每个资源节点上都需要驻留一个系统管理代理的组件实例SM_AG_I_X，它用于管理整个资源计算节点，向上作为系统管理组件命令的执行者，向下作为本节点的管理者，执行本节点上系统管理指令，完成本节点上的组件实例调度。

3 备份关系设计

在系统中，针对组件的安全关键等级设置不同的备份方式，主要包括主从备份和冷备份两种方式。

3.1 组件实例的主从备份

主从备份中的备份组件实例驻留在单独的计算资源节点上。对于具备主从备份的组件实例，规定主从备份的主组件实例处于运行状态，承担相应的组件服务角色，从组件实例处于启动状态，与主组件实例承担同样的服务角色。两个实例的差别是，主组件实例在正常工作时，从组件实例持续接收系统的状态更新，从组件实例虽然启动，但不参与系统中的决策。

3.2 组件实例冷的备份

冷备份中的备份组件实例驻留在单独的计算资源节点上，而且该备份组件处于未启动状态。与主从备份的区别是,一般冷备份用于主组件实例驻留的资源节点发生故障，需要进行资源的迁移备份。此时,位于单独计算资源节点上的冷备份开始启动，接替主组件实例的工作。

系统中，可以选择某个通用处理资源节点resource_nodeX作为其他N个节点备份，当N个节点中的Nj发生故障，可在该备份节点上，启动Nj节点上的应用。

4 系统管理应用举例

给定当前系统构型与状态，举例说明系统管理对资源的管理过程。在系统中，主从备份和冷备份的组件实例关系见表1。

表1 组件实例关系表Table 1 Component instances relationship

4.1 组件实例重启

当系统管理组件综合节点上系统管理代理上报的组件实例和资源状态综合判断发现组件实例出现故障，而该实例驻留的计算资源节点正常时，系统管理则通过系统管理代理控制资源节点上的某个组件实例进行重启，实现组件实例功能的可用性。

4.2 组件实例功能迁移

当系统管理组件综合节点上系统管理代理上报的组件实例和资源状态综合判断发现主组件实例故障且经过重启后，仍不能正常工作时，系统管理组件通过代理组件关闭主组件实例，并启动从组件实例，如图8所示。

图8 组件实例功能迁移Fig.8 Component instance function migration

在组件实例功能迁移的过程中，系统管理根据系统配置表，通过图1中间层结构关系进行消息传输。首先，通知DDS服务组件(DDS服务组件在网络驱动之上为应用程序提供消息收发和服务质量的功能)，com1A服务角色的承担实例发生改变，由组件实例com1_I_1变成组件实例com1_I_4；然后，DDS服务组件在投递消息时，只需要将消息目的端更改为组件实例com1_I_4的地址；最后，网络层则按照新的目的地址路由进行消息发送。在以上过程中，因为定义了服务角色，隔离了组件实例与数据消息的传输关联性，当主从备份切换时，ICD可以复用，不需因目的组件实例的改变而重新定义。

4.3 组件实例资源迁移

当系统管理组件综合了节点上系统管理代理上报的组件实例和资源状态，综合判断发现主组件实例驻留资源故障，系统管理组件通过代理组件关闭该资源节点，并启动其他资源上的冷备份组件实例，如图9所示。

图9 组件实例资源迁移Fig.9 Component instances resource migration

在组件实例资源迁移的过程中，系统管理根据系统配置表，通过图1中间层结构关系进行消息传输。首先，通知DDS服务组件，com2A服务角色的承担实例发生改变，由组件实例com2_I_1变成组件实例com2_I_3；然后，DDS服务组件在投递消息时，只需要将消息目的端更改为组件实例com2_I_3的地址；最后，网络层则按照新的目的地址路由进行消息发送。

组件实例功能的迁移是主、从两个组件实例均已工作，从组件实例作为热备份实例，且实时接收系统中的状态，当主、从组件实例切换时，原来的主组件实例变成了从组件实例，原来的从组件实例变成了主组件实例，只是功能的迁移，与计算资源无关。

组件实例资源迁移是在系统中预留特定的计算资源，作为一个或多个组件实例的备份资源空间，这些组件实例处于未启动状态。当原计算资源故障，该计算资源上所有的组件实例均停止工作，系统管理组件根据系统的构型，在新计算资源上启动被关闭组件实例的冷备份组件实例。

4.4 系统配置信息表

上述系统管理过程可以用系统的配置信息表描述，见表2。

表2 系统配置信息表Table 2 System configuration table

5 结束语

本文提出的基于分布式航电系统的系统管理配置方法，具备以下优点：

1) 改变了传统ICD的设计观念，将消息的源、目的与物理形式的设备解绑，做到数据只与应用相关；

2) 通过系统管理的系统配置表，描述了系统架构、组件实例与资源的关系、组件实例与角色的关系、角色与组件的关系以及所有的消息源、目的及消息本身参数信息的全部信息，重构策略不用基于预先穷举的固定配置，而是根据实际情况灵活可变；

3) 当系统中增加或减少设备时，不会影响组件应用及ICD接口等顶层设计，只需在系统配置表中配置新消息或删除消息；

4) 系统重构发生时，作为面向用户的应用层，不感知由重构带来的消息目的端及链路的变化，实现应用与资源的无关性；

5) 实现应用间交互关系(ICD通信关系)和网络通信关系(网络通路的建立)之间解耦，两者关系可独立变化。

本文提出的系统管理配置方法，能够保证当组件实例或者资源节点发生故障，导致航电系统无法完成既定功能时，通过对资源进行调配，实现系统重构，恢复航电系统功能。