航天器软件体系结构研究
作者：侯成杰
中国空间技术研究院北京控制工程研究所研究员、主任测试师。中国空间技术研究院软件专家组资深成员，主要专业方向为软件测试、软件产品保证。从事航天器软件测试工作20余年，先后负责过载入航天、探月工程、各种卫星等国家重点型号的数百个航天器关键软件的测试工作。先后独立或者参与编制多份航天器软件测试、软件产品保证方面的技术标准，并出版软件测试技术专著1本。
摘要：对国外航天器软件体系结构的研究及应用情况进行系统梳理，重点介绍具有可即插即用特点的美国空军的SPA体系结构和具有可运行时维护特点的NASA的CFS体系结构，分别总结了这2种体系结构的核心技术：即插即用软件技术和软件总线技术。介绍了国内航天器软件体系结构中的分层体系结构和软件总线体系结构。在此基础上，总结了航天器软件体系结构的关键技术，包括软件复用技术、即插即用软件技术、软件自主诊断及修复技术。根据国内的研究现状，提出了基于国外开源软件框架或自主研发等的发展建议。
关键词：航天器软件体系结构；SPA体系结构；CFS体系结构；分层体系结构；软件总线
引言
作为控制软件复杂性、提高软件系统质量、支持软件开发和复用的重要手段之一[1]，软件体系结构日益受到关注，并发展成为软件工程的一个重要的研究领域。软件分层的思想在软件体系结构设计中扮演着重要的角色，软件的分层体系结构最早在智能机器人[2]领域得到应用，也是嵌入式实时系统普遍采用的体系结构模型。而在软件分层体系结构的基础上，将体系结构的某一层或者某几层应用之间采用类似于数据总线的方式进行连接，又衍生出了基于软件总线的体系结构。软件总线属于软件体系结构的一种。软件总线的概念最早是在公共对象请求代理体系结构（CORBA）规范中提出的，在CORBA规范中，软件总线指的是CORBA定义的一组独立于语言和环境的接口规范，通过遵循这些接口规范，组件之间可以实现相互通信，共同完成特定的客户任务。
美国空军和NASA的一些研究机构借鉴了软件总线和软件中间件思想，在航天器软件研制中采用了软件总线模型。其关键在于建立一个高效的总线结构，使各软件部件之间能以一个公共的接口互相连接，做到部件即插即用、无缝集成。
研究航天器软件体系结构的主要目的是为了解决软件复用和易于维护等技术问题，目标是找到一种能支持软件更高复用程度、更容易维护的体系结构。
软件复用按不同阶段软件产品抽象程度的高低，可分为体系结构复用、构件（模块）复用、代码的复用（克隆）、分析的复用、设计的复用和测试信息的复用等类型。其中体系结构复用+构件复用是最高层次的复用。在体系结构可复用的前提下，进一步实施构件（模块）的复用可以大幅度提高软件生产效率。
航天器软件的易于维护既包括研制过程中的软件升级维护，也包括方便航天器软件实施在轨维护。为使软件易于维护，希望降低软件模块之间的耦合性，即对某一软件模块的更动对其他模块没有影响。同时航天器软件通过在轨维护方法来修正已知的软件设计缺陷和错误，或者适应用户新需求的变化。目前的在轨维护过程需要软件停止运行一段时间（几分钟到十几分钟），这显然无法满足一些对于在轨维护实时性要求高的[3]航天器应用场景。应该尽量减少软件维护时的停机时间，最理想的情况是软件可以在运行时不停机进行维护。而要求更高的维护场景如月球着陆器落月、火星探测器降落等过程时间非常短暂而且不可逆，如果在这个过程中发生软件故障，采用传统的在轨维护方式将无法满足要求，因此该类航天器软件应具备在线自主诊断和自主修复能力。综上所述，为满足航天器软件工程实际需求，应研究同时满足上述软件复用要求及维护性要求的软件体系结构。
1、国外发展及应用情况
1.1 美国空军实验室空间即插即用电子系统
美国空军实验室（AFRL）提出的[4]空间即插即用电子系统（SPA），是一套参考自适应即插即用技术的接口驱动标准。即插即用软件技术是SPA的核心，具有自动发现识别部件、自动注册部件和为部件自动配置及订阅服务等功能。
SPA软件系统采用分层结构[4]，共分为4层，如图1所示。最底部是部件层，由各种部件组成。部件层之上是中间层，中间层又叫做卫星数据模型（SDM），它是SPA软件的核心。应用层在中间层之上，通过应用层接口来访问SDM中的即插即用部件。SPA软件的最顶层为任务层，通过调用应用程序实现特定的任务，如导航、遥感等。
SPA软件体系结构已经成功应用于美国研制并发射的SPA-1 Trailblazer（空间即插即用先驱者一号，美国新墨西哥州大学等研制）、KySat-2（肯塔基大学立方体卫星二号）、ORS-2（作战及时响应太空二号）等卫星，以及日本研制并发射的RISESat微卫星上。它采用部件自描述技术和即插即用软件技术，主要用于解决软件维护性（即插即用）问题。同时，它所采用的分层结构，也可以解决体系结构层面和部件层面的软件复用问题。
a. 部件自描述技术
部件自描述技术指通过电子表格xTEDS（extensible Transducer Electronic Data Sheets，扩展转换电子数据表格）来描述部件自身的即插即用信息。当部件接入到SPA后，星务软件可以通过这些即插即用信息获取部件的各种数据。该电子表格采用XML语言描述，里面包括器件信息、接口信息，接收的指令集合和可传输的数据模式等信息。星务软件根据协议从硬件接口中获取当前部件的xTEDS文件，并根据此xTEDS文件为部件配置服务或者订阅部件所提供的服务。
b. 即插即用软件技术
SPA软件可以支持部件的即插即用，可以动态地检测部件的接入或者删除状态，并相应完成对部件的注册及部件数据服务订阅等功能。该技术的核心是SDM。SDM可以获取部件本身存储的xTEDS信息，通过对xTEDS信息进行解析来获取部件的信息，包括部件可以提供什么数据和需要获取什么数据。在这个过程中，SDM仍然可以响应正在运行的应用程序的请求，根据它请求的信息为应用程序和实际的物理部件构建一个源宿匹配关系，实现部件服务的配置和订阅功能。SDM还能够通过路由信息判断部件是否被删除，一旦部件被删除SDM可以终止上述的服务请求匹配过程。通过即插即用软件技术，SPA 软件系统很好地解决了软件维护问题。SDM分为数据管理器、任务管理器、敏感器管理器、处理器管理器等4部分。数据管理器又是SDM的核心，它负责在系统中维护数据生产者和消费者的信息，并负责xTEDS 信息的注册、查询以及存储功能，处理应用程序的请求，包括注册信息请求，数据订阅请求等。数据管理器又分为[5]当班数据管理器和备份数据管理器，备份数据管理器定时查询并监控当班数据管理器的状态，当班数据管理器定时把软件重要运行状态发送给备份数据管理器存储起来。如果当班数据管理器发生状态异常，SDM可以自主“平顺”地切换到由备份数据管理器当班而不影响软件的正常运行。
1.2 NASA的CFS体系结构
NASA戈达德空间飞行器中心提出了核心飞行软件CFS（Core Flight Software，）体系结构[6]，该体系结构已经在“全球降水量测量”（GPM）卫星等至少3个在轨飞行航天器中得到应用。CFS体系结构也属于分层结构。除了开发环境以外共分为5层（见图2），即操作系统及BSP层、平台抽象层、核心飞行程序（cFE）层、应用程序库函数层和应用程序层。NASA在采用分层体系结构基础上，针对cFE层进行了专门设计，将其作为独立的、可重用的核心飞行软件服务和操作环境任务集，并提供软件总线服务，通过软件总线管理各个应用程序发布的消息，并在各应用程序之间进行通信及消息主题匹配。软件总线的主要功能是提供信息交互的机制，使信息可以在应用程序之间交互传输。CFS体系结构中的核心技术包括以下2个方面。
a.面向软件复用的开发接口
在解决软件复用问题方面，cFE层及以下各层的代码完全复用，不可修改。但是可通过调整配置参数来适应不同平台或任务。应用程序开发人员可使用cFE提供的标准API开发应用层程序及应用程序库函数层程序，以完成所需要的功能。这些应用层程序及应用程序库函数程序可以根据其功能和适用范围分别标识为可重用模块或者某型号专用模块，方便在开发不同型号应用程序时进行使用。使用CFS进行开发的层次复用关系见图3。
b. 软件总线技术
在该体系结构下，各应用程序（部件）之间通过软件总线进行通信。其核心技术与SPA体系结构类似，也是数据部件的注册以及部件数据服务订阅机制。增加新的部件当于新增一个数据发布者和新的数据主题，软件总线将匹配该主题和已有的数据订阅者，匹配成功就意味着该部件被接入总线。而删除软件构件过程则更简单，只需直接将被删除部件所发布的数据主题和所订阅的数据主题都删除即可。基于软件总线实现新增部件和删除部件过程时，不影响其他部件的运行，即部件可以在运行时进行加载和删除。应用程序开发人员可以使用cFE提供的标准API开发所需应用程序（部件），这些应用程序均通过软件总线的信息发布和订阅机制接入软件总线。基于CFS系统开发的GPM航天器软件体系结构如图4所示[7]。从图中可以看出：绿色的环线为cFE提供的软件总线示意，不论是CFS已经提供的应用程序（蓝色方块）还是应用程序开发人员开发的GNC应用程序（黄色方块）、数据管理应用程序（浅黄方块）等均只和软件总线进行交互，从而避免了这些应用程序在加载和删除时对其他程序的影响。GPM航天器所使用的基于软件总线的体系结构见图4。
图4 GPM航天器所使用的基于软件总线的体系结构
Fig.4 Software bus on GPM Spacecraft
2、国内研究及应用情况
目前，中大规模的国内航天器软件中已经广泛应用实时操作系统，如商用的VXWORKS或者自研的实时操作系统。基于实时操作系统开发的航天器软件普遍采用分层体系结构，并且基于分层体系结构开展不同型号之间的软件复用。除了分层结构之外，国内航天器软件研制中尚未采用其他体系结构，但是开展了相关研究工作，并取得了一定成果。
2.1 卫星软件的分层体系结构
分层体系结构中比较有代表性的是卫星软件的3层体系结构，该体系结构包括系统软件层、系统应用层、用户应用层。每个层次又可以根据功能细分为几个不同的层。文献[8]在通用的3层体系结构基础上，将系统应用层进一步分解为输入输出层、数据应用层、数据交换层、核心调度层，得到了如图5所示的体系结构。
图5 卫星软件三层体系结构
Fig.5 Three-layered software architecture of satellite
系统软件层和用户应用层的配置是国际上航天器分层软件体系结构的一般性认识。系统软件层一般包括硬件描述层、操作系统层和端口驱动层等．用户应用层则与航天器的功能相关，一般包含平台应用模块（与航天器载荷功能相关）、姿轨控模块、温度控制模块、有效载荷管理模块和存储管理模块等。系统应用层是三层体系结构的中间层，针对软件体系结构的研究主要集中在该层。上述3个子层均采用标准化、通用化的设计，针对不同卫星平台应用时通过调整配置参数来进行接口的增加和删除、通信协议的配置等。
该体系结构的主要研究重点在于软件复用方面。分层模块化体系结构可以解决体系结构层面和构件层面的复用问题。一个新的卫星软件，可以直接引用软件体系结构及其代码框架，卫星硬件的不同可以在硬件描述层通过修改配置文件来解决；接口的不同可以通过在端口驱动层增删驱动程序来解决；外接设备的不同，可以在数据应用层根据通信协议增删新的产品模块，而用户应用层可根据不同分系统的具体软件需求进行模块增删或模块改进。总之，需求变化引起的软件改动仅影响模块的增加或删除，并且限制在一个层内，而不影响其他层，由此可以实现体系结构的复用。但是，该体系结构没有对软件易维护性进行研究和针对性设计。
文献[9]中基于该体系结构开展了软件产品化研制及管理研究，按照卫星平台和产品系列划分，已有60余个软件或FPGA产品配置项纳入软件产品化型谱。
2.2 航天器姿态轨道控制软件的软件总线体系结构
文献[10]中研究了NASA等研究机构的软件总线体系结构，结合卫星姿轨控软件特点，提出了如图6所示的软件总线体系结构。该体系结构采用以数据为中心的设计思想，把软件的各个功能模块进行构件化设计成为软件构件，这使得姿控系统软件中的各个功能模块能够得到重复利用，减少程序编码的复杂性。软件构件包括控制模式管理构件、姿态测量和数据采集构件、各种定姿构件、各种姿态控制器构件、轨道控制器构件等。
图6 航天器姿轨控软件总线体系结构
Fig.6 Spacecraft AOCS software bus
从图6可以看出，基于总线的体系结构只有1层，所有构件均只和总线进行通信，构件之间的所有交互（包括普通调用、参数传递等）均通过总线进行，它简化了传统软件体系结构中多层次模块之间的调用关系，使得构件之间的相互影响降到最小，从而大大方便了单个构件的维护过程。
该体系结构也采用发布者/订阅者模型来实现构件之间的数据传输：当一个构件希望发布一个主题的数据时，它必须创建发布者和发布主题；当构件希望接受某个主题数据时，它必须创建数据订阅者和发布订阅主题。基于软件总线的姿控系统软件体系结构设计改变了姿控系统软件各个功能模块的调用机制，改变了各个功能模块的数据传输通道，可以方便完成对各功能模块的调用、增加和删除。该体系结构尚未应用于型号软件研制实践，但是其核心技术已经具备应用的基础。
3、航天器软件体系结构的关键技术
通过上述对国内外航天器软件体系结构研究及应用情况的分析，可以从中梳理出如下关键技术。
3.1 软件复用技术及支持软件复用的开发平台
NASA的CFS体系结构采用的是基于配置参数的复用技术，并且提供了面向应用开发者的开发接口（API）。传统的“代码克隆”式复用已经不能满足国内航天器软件研制中针对多航天器、不同层级多配置参数的软件复用要求，必须建立支持软件复用的开发平台，对不同航天器应用软件的源代码、目标代码、配置参数之间的对应关系进行管理。应用程序开发人员使用该开发平台，根据不同航天器软件需求，选择适用于所开发航天器应用程序的不同层级的配置参数（包括所使用的处理器、操作系统、不同部件的配置参数等），并生成满足本航天器需求的复用软件源代码和目标代码。
3.2 即插即用软件技术
不论是SPA软件体系结构中所采用的即插即用软件技术，还是CFS体系结构中所采用的软件总线技术，其实质都是软件运行时维护技术。该项技术的核心是软件部件定义以及软件部件之间的数据通信，包括部件通信策略、对部件的调度与管理策略等。部件通信策略一般采用发布者/订阅者机制，目的是发送适当的信息给合适的接收者。对部件的调度策略一般是为部件数据分配内存，软件总线调度器将部件发送来的数据存入内存区，在一定时间间隔后，软件总线控制器查询内存区，再将数据发送到对应部件。基于软件总线的体系结构需要订阅和发布的通信机制具有较高的性能和可预测性，保证资源得到有效使用。对部件的管理策略是指软件总线控制器根据软件部件之间的通讯数据对部件进行调用、加载和删除。
3.3 软件自主诊断及修复技术
在SPA体系结构中涉及到了软件自主监控及重构技术，在CFS体系结构中没有涉及，这是由于航天器自主诊断及修复技术往往涉及到各研究机构的核心技术，与航天器系统设计密切相关。软件自主诊断及修复的代表技术包括采用软件构件级容错技术[11]以及功能容错[12]技术等。其中，构件级容错技术与软件自主监控及重构技术有一定的相似性，都是采用切换备份构件的策略。而功能容错技术则需要在航天器系统功能层面进行统一规划，需要对各类在轨事件进行分级分类，对不同级别不同类型的故障事件制定相应的软件自主处理策略，如日常维护策略、故障自恢复策略、故障自重构和欠配置运行策略等。
4、启示与建议
NASA等国外研究机构已经成功基于分层结构解决了航天器软件重用问题，基于软件总线来解决了软件即插即用问题，国内学者借鉴了NASA的研究思路，提出了面向卫星姿态轨道控制软件的软件总线体系结构，因此分层结构＋软件总线可以作为未来国内航天器软件研制所采用体系结构的思路。基于该思路可以有两个发展方向。
（1）基于cFE开展后续研究及开发工作。NASA已经把cFE框架作为开源软件进行了开放，并欢迎全世界的航天器软件研制人员交流和使用。目前，已经有除了戈达德空间飞行器中心之外的NASA其他中心采用了该框架，并有美国之外的研究机构进行了研究实践，但尚未见到在航天器研制中应用的消息。国内航天器软件研制单位可以基于cFE开源软件开展研究，并探索基于cFE进行不同类型航天器软件开发的可行性。
（2）建立自己的分层结构＋软件总线体系结构框架，并并基于该框架开展面向支持软件重用、软件自主修复、软件部件即插即用等方面的研究，并建立自己的类似于cFE的航天器软件开发环境。研究工作可分步骤进行。第一步先基于现有分层结构建立支持软件复用的开发环境，该环境支持通过修改配置参数来生成不同型号适用的航天器软件，以及将复用软件部件加入软件配置项等功能。第二步则在此基础上建立软件总线体系结构，并基于软件总线体系结构实施软件自主修复和即插即用。
-End-
