卫星综合软件的体系结构研究

王 磊，袁 利

(北京控制工程研究所,北京 100190)

随着卫星功能的复杂性不断提高，卫星电子线路的集成度也越来越高，软件也逐渐集中在一起运行，形成综合软件.不仅其功能复杂，而且规模变大，这对于软件的开发和维护都提出了新的挑战.目前国内的卫星软件开发技术和软件架构的局限性已经表现得非常明显.

对于复杂的大型卫星综合软件，需要系统地宏观结构设计，能够长期准确地把握用户需求和系统构成的实质和特点，并指导以后的设计和实施活动，包括对系统的性能进行预测和分析、设计和管理、测试和维护.与传统设计方法中各种系统结构描述不同，体系结构在系统构成、内部关系和实现约束的描述方面更深入、更细致，而且包括系统设计的各个方面.因此，软件体系结构是整个项目设计的第一步，对以后各种设计和实施具有指导、控制和管理作用.体系结构的设计成为关系到复杂系统设计成败的关键步骤，其作用表现在软件设计开发的规划、需求分析、设计、实施、评估和维护等各个阶段.

20世纪90年代以来，美国和欧洲新研制的卫星平台大多数使用集成的电子系统和实时多任务的操作系统(以VxWorks和RTEMS两大系统为主)，在规划和需求分析阶段建立软件的体系结构，并为此后的设计提供指导.例如MER(mars explorer rover)[1]的应用软件从下向上分为5个层次，包括硬件存取、硬件驱动、核心应用、载荷及任务应用以及行为层；德国的CubeSat小卫星平台[2]的软件从内向外分为3个层次，包括系统内核、应用和接口，另外还包括一个独立的支持软件库；法国的Space bus 4000B通讯卫星平台[3]的软件从下向上分为3层，包括：操作系统、平台服务和应用.星载软件按照分层设计的还有Smart-1月球卫星[4]、CHAMP卫星[5]、PROBA卫星[6]、SAX卫星[7]、Spot卫星[8]等，涵盖了从低轨到高轨，从小卫星到导航通讯卫星，从地球轨道到深空探测等各类卫星.

目前国际上在星载软件体系结构方面的研究和应用比较多，方便了同一个卫星平台的多颗卫星的软件研制.然而，虽然层次型结构是星载软件普遍适用的思想方法，但目前国际上星载软件体系结构与卫星平台的结合过于紧密，分层不能进一步清晰化，妨碍了卫星平台之间在体系结构上的通用.

国内卫星一般采用分布式设计，主要的姿轨控分系统、数管分系统和有效载荷分系统的软件均在各自的处理器上运行，以结构化设计方法和分时多任务设计为主，软件体系结构的概念不够清晰.但电子线路集成是国内今后卫星电子线路研制的发展趋势，原属于各个分系统的独立软件也将集成到单个计算机上运行，软件的功能复杂度和规模均有大幅度的提升.

本文针对国际星载软件体系结构在不同卫星平台间通用性不强的特点，提出一种跨平台的卫星综合软件的分层模块化体系结构，在明确的系统应用层中体现不同卫星平台的共性和差异，适用于国内今后采用综合电子系统的各类卫星平台.对该体系结构的组成、功能和层次结构进行了详细描述，对该体系结构在软件复用、设计与测试等方面带来的优势进行了深入分析.

1 综合软件的分层模块化体系结构

从软件研究和设计的发展历史看，层次型结构一直都是软件分析和实际实施的基本、普遍适用的思想方法.尽管每个卫星软件的功能千差万别，但都是可以建立在描述层次上的，层次性是软件体系结构的不变性，是软件构成的共同规律，也是嵌入式实时系统普遍采用的结构模型.本文所描述的分层模块化体系结构如图1所示.

图1 综合软件的体系结构

分层体系结构自下往上包括3个大的层次，分别为系统软件层、系统应用层和用户应用层，每个层次又可以根据功能细分为几个不同的层.其中系统软件层和用户应用层的配置是国际上星载软件体系结构的一般性认识，本文所述体系结构的重点集中在系统应用层.

1.1 系统软件层

系统软件层包括硬件描述层、操作系统层和端口驱动层.

硬件描述层是对计算机以及外围器件的描述，通常用一组描述文件来定义，这组文件称为BSP(board support package).不同的卫星平台，虽然其计算机系统硬件的不同，但可根据不同的CPU体系在模块组成上具有统一的形式.操作系统层包含两个部分，一部分是用于启动和加载的引导程序，另外一部分是嵌入式实时多任务操作系统.引导程序用于加载软件和处理加载过程中出现的问题.嵌入式实时多任务操作系统具有一个多任务的内核，内核调度的基本单位是任务，允许将实时应用构造成一套独立的任务集合，每个任务拥有各自的执行线程和自己的系统资源集合，来完成不同的功能.实时多任务操作系统是按照事件实施调度，不同于分时操作系统的按照时间进行调度的策略.国外90年代以来卫星平台上使用的实时多任务操作系统有VxWorks、RTEMS等，国内也有多个单位在研发适合于我国卫星使用的实时多任务操作系统.

端口驱动层在端口配置文件支持下，提供一组针对不同的端口可在实时多任务操作系统下运行的驱动程序，包括查询模式和中断模式两种操作方法.端口驱动层构成了对硬件的完全封装，应用软件可以不再考虑硬件问题.

1.2 系统应用层

1.2.1 输入输出层

输入输出层是应用软件和硬件系统的接口层，该层调用端口驱动层的驱动程序，完成应用软件对外部设备的数据输入和输出，所包含的模块对应于系统所包含的接口(如RS422、CAN、LVDS、1394、1553B等).在实时多任务操作系统的环境下，输入输出层的每个模块用于对指定端口的管理，由于存在多个任务可能向同一端口(总线端口或片选端口)发出(和接收)数据的可能，因此，输入输出层的管理就是为了保证在实时前提下有序地发送数据和接收数据.

通常采用消息队列或管道方式.例如多个应用层任务需要向同一端口发送数据时，可以按照各自的优先级在获取可发送信号量的前提下向一个发送队列传递消息，输入输出层的对应模块从队列中取得消息，然后发送.当某一个接口进入数据时，输入输出层的对应模块将读入的数据按照包格式发往一个接收消息队列，数据应用层的模块负责从消息队列接收数据包，进行解包.

不同的卫星平台，其接口有所不同，在输入输出层按照接口进行模块化设计，便于裁剪，可以完成不同卫星平台硬件接口的完全封装.

1.2.2 数据应用层

数据应用层是应用任务和输入输出层之间的翻译层，用于实现所有外接设备的数据通讯协议.即应用任务需发出的数据经过数据应用层的对应模块根据通讯协议打包后发往输入输出层，同样的，输入输出层接收到的外接设备的数据包，由数据应用层根据通讯协议解包后经数据交换提供给应用任务.

向挂接在同一总线上的外部设备发送指令或数据时，只要向对应接口的消息队列发送消息数据包即可，对于实时性要求高的外部设备，可将消息数据包的优先级提高.

数据应用层的模块按照外接设备定义，一个外接设备对应于一个模块.例如可以包括如下模块：数字太阳敏感器、红外地球敏感器、星敏感器、相机、动量轮线路盒、帆板驱动线路、有效载荷线路盒等.这些模块可以随着不同卫星平台的设备配置增加或删除.每一个模块根据与对应设备的通讯协议编写.而产品化的敏感器和执行机构的数据应用层模块可以在多个型号中通用.

1.2.3 数据交换层

数据交换层完成应用模块的任务之间的数据交换以及应用模块的任务和数据应用层之间的数据交换.分为4个模块，如表1所示.

表1 数据交换模块

数据交换层是信号量、队列和全局变量之间对应关系的集合，这些关系表达了任务之间的数据耦合和时序耦合.不同卫星平台，当功能有差异时，实现功能的任务集合也会增加或减少，对任务的解耦以及聚合均在数据交换层体现.

数据交换层的4个模块涵盖了多任务之间的数据交换方式，在针对具体卫星型号时，可根据实际需要进行裁剪.

1.2.4 核心调度层

核心调度层可以包括4个模块：遥控处理模块、故障诊断隔离和恢复模块、在轨任务管理模块和系统管理模块.其中遥控模块用于处理地面遥控指令，对接收到的遥控指令进行验证、解释并发起对应的任务执行或传递指定的参数到其他任务.故障诊断隔离和恢复模块用于执行用户定义的故障诊断、隔离和恢复功能，这个模块是由用户自定义，在系统级处理故障问题，将原分散于各个模块的故障诊断功能集中到一起，包括健康管理.在轨任务管理模块用于处理地面的任务级指令、程控指令、自主操作等工作.系统管理模块用于处理卫星自身硬件和软件的维持、维护、监控、通道的管理、时序的安排等工作，也包括应急处理和安全监控.

核心调度层是保障接收地面指令、维护系统安全、提供应用管理的模块集成，是应用软件的核心，由该层来表征应用软件自身的健康状态，可用于发送针对容错线路的清狗指令.

核心调度层是不同卫星平台差异最大的部分，根据特定卫星平台的设计要求，核心调度层可以增加或删除以上模块中的子模块，并且每个模块的内容在不同平台下也很可能不一样.将不同卫星平台的差异限制在核心调度层内，有利于提高软件体系结构的稳定性.

1.3 用户应用层

用户应用层包含几个大的模块，有平台应用模块、AOCS模块、温度控制模块、有效载荷管理模块和存储管理模块，这些模块可以根据不同卫星平台的分系统的配置情况进行设置.

一般地，平台应用模块包括：遥测模块、采样模块、时间管理模块等；AOCS模块主要包括姿控和轨控的算法；温度控制模块主要用于星上自主温控的控制律实现和工作模式管理；有效载荷模块针对不同卫星型号的载荷不同，其功能也不同，原则上都是对有效载荷的工作实施调度；存储管理模块专门针对星上大容量存储器的数据进行管理，复杂一些的设计可以采用可靠文件系统.

2 分层模块化体系结构下的设计与测试

2.1 模块设计

分层模块化的体系结构通过分层来明确卫星综合软件的组成结构，通过模块化来覆盖软件的功能.每一个模块均采用封装的方式，定义其输入输出接口，模块之间的数据交换全部在数据交换层实现，模块的调用由核心调度层完成，核心调度层不仅能够调用模块，还可删除模块，以保证整体软件安全.

每一个模块可以采用结构化的设计方法或基于对象的分析设计方法实现，只要符合输入输出接口的规定即可.在实时多任务环境下，一般地，每个模块用一个主任务和几个从任务实现，从任务可选.而任务的优先级则作为调用时的模块输入参数指定，这样可以不破坏软件整体时序结构.

每一个模块由于采用封装方式，因此不会干预其他模块的运行，而数据交换仅通过专门的数据交换层进行，保证不会出现数据的交叉覆盖，所交换数据的可靠性由模块自行判断，每个模块的运行情况通过一个全局的错误变量向核心调度层反馈.

2.2 实时多任务设计

包含多个功能模块的体系结构，是把这些模块按照一定的规则组织起来，既适应于不同型号之间的差异，也能适应同一个型号用户需求的不断修改，让软件明晰化，方便分工和过程管理.

基于实时多任务的软件体系结构包括如下几个方面：任务的划分；优先级结构；发起和退出规则；任务之间的同步与互斥关系；任务之间的数据通信机制；任务与中断的相互关系.

任务的划分则需遵守H.Gama原则，包括：

(1)I/O原则：对于单独的接口，应该使用单独的任务处理，不同的接口使用不同的任务；

(2)优先级原则：对于突发性事件，应划分为不同优先级的不同任务；

(3)同优先级原则：对于功能类似，而接口不同的功能，应划分为优先级相同的任务；

(4)大量运算：服务于大量运算的功能部分，其优先级应安排的低一些；

(5)功能耦合：将关系密切的若干功能组合起来，归为一个任务；

(6)偶然耦合：归为一个任务；

(7)频率组合：对于经常重复发生的事件，发生频率不同的事件划分为不同的任务.

进行任务划分时，除了遵循以上原则以外，还需考虑所实现功能间的异步关系.如果在具体分析一个功能时发生原则冲突，则要为每一个原则针对具体的功能设定“权重”，必要时可以通过计算“权重”来最终确定如何划分任务.

任务划分可以归为3类：

(1)周期任务：是指有固定周期要求，每个周期必须完成一次的任务；

(2)事件任务：是指等待某一事件的发生而采取行动的任务，一般地，事件是以消息的方式产生；

(3)异步任务：是非周期性任务，根据命令执行和用于处理内部事务的任务.

2.3 软件复用

软件复用按不同阶段软件产品抽象程度的高低，可分为代码的复用、分析的复用、设计的复用和测试信息的复用等类型.在国内卫星软件开发过程中，这几种类型的复用都涉及到了，但复用水平并不高，其中一个主要原因是几乎没有可复用的体系结构，复用主要针对某个具体的函数或某段相同功能的源代码进行，使得卫星软件复用的层次不高，范围较窄.

分层模块化体系结构可以解决体系结构层面和构件层面的复用问题.一个新的卫星软件，可以直接引用本文所描述的软件体系结构及其代码框架，卫星硬件的不同可以在硬件描述层通过修改BSP文件来解决；接口的不同可以通过在端口驱动层增删驱动程序来解决；外接设备的不同，可以在数据应用层根据通讯协议增删新的产品模块，而用户应用层可根据不同分系统的具体软件需求进行模块增删或模块改进.总之，需求变化引起的软件改动仅影响模块的增加或删除，并且限制在一个层内，而不影响其他层.由此可以实现体系结构的复用.

体系结构内的模块由于采用封装方法，因此，如果两颗卫星所采用的产品是相同的，则软件体系结构中对应的模块是可以直接复用的，前提是在体系结构已经复用的基础上.在硬件产品化的基础上，就可以实现对应软件模块的产品化.例如：针对不同CPU体系的BSP可以模块化复用；针对不同端口的驱动可以模块化复用，针对指定敏感器或执行机构的数据应用层模块可以复用，AOCS模块里可以通过规范化算法进行复用等等.于是，产品化的软件模块即构成了可复用的构件.

因此，在具有可复用的体系结构的前提下，构件(模块)的复用可以大幅度提高软件生产效率.

2.4 软件测试

在以体系结构为指导的软件设计思想下，软件的测试将与以往大不相同.测试的工作提前到设计阶段，即在设计阶段考虑测试问题，形成可测试设计，可以在测试阶段提高测试效率.

采用跨平台的星载综合软件体系结构，设计工作大致可以分为两类，一类是可复用的分层模块化体系结构和模块的设计，一类是针对指定卫星的特殊模块设计以及组装.

前者首先根据不同的卫星平台建立该平台的分层模块化体系结构，包括相关文档和标准代码架构，设计工具软件用于自动生成该平台的软件系统的体系结构源代码，这样的体系结构系列是有限的，可在平台的系列卫星上重复使用.其次在平台内部整理端口和部件产品，对每一个端口和产品化的部件开发其在该体系结构下的对应标准模块，将每一个模块形成构件代码，建立构件库.在大部分时候，模块是可以跨平台形成构件库的，前提是不同平台的体系结构是复用的，而且操作系统是相同的.

后者是针对指定的单个卫星的软件开发，首先生成所属平台的体系结构代码，其次根据其端口和部件产品的配置选择模块构件，对于该卫星特有的模块专门开发实现，最后组装在一起，这样可以避免大量的重复开发，大大提高效率.

在这样的开发过程中，对于单个卫星的软件测试相应的减少了很多工作.例如，可以取消体系结构代码的测试和复用模块的测试，仅对专有模块进行单元测试以及对整个软件进行回归测试即可.这样，可以节省软件生产者的大量工作，可以快速地完成软件，参与系统测试.

3 结 论

随着卫星软件集成度和复杂性的快速提高，软件规模的不断变大，软件体系结构设计变得越来越重要，独立的软件体系结构设计阶段是必不可少的，理论和实践都证明，良好的、易于维护的体系结构设计，对于降低设计风险、提高软件质量、保证开发速度都是至关重要的.本文提出的卫星综合软件的分层模块化体系结构，在软件的设计、测试和复用等方面都表现出优势.