张亚航 杨培尧 赵思阳

(北京空间飞行器总体设计部，北京 100094)

软件架构用于软件模块与模块，软件与环境之间的关系进行全局描述[1-2]，软件架构决定了软件本身的通用性、灵活性和适应性[3]。传统卫星的设计思路大多数是先根据任务需求确定硬件结构和配置，其次开发底层软件处理各种硬件信号将硬件连通，然后在硬件功能基础上设计开发软件以实现相关功能；而软件任务模块之间的交互往往是事先约定数据格式和内容，然后进行调用或数据传输。这种模式下，首先软件设计思路容易围绕硬件，导致软件对不同硬件的差异适应能力较差，其次软件任务模块与任务模块之间的耦合性极高，难以对软件功能进行拆分和重组。

本文描述的中型敏捷遥感卫星公用平台(ZY2000 Remote Sensing Satellite Platform)开放式分层软件架构明确了各个层次主体功能和对外接口，并最终建立了简洁灵活的软件架构，即开放式分层软件架构。该软件架构在更新换代、全面使用空间数据系统咨询委员会(CCSDS)、欧洲航天标准合作组织(ECSS)等国际标准的基础之上，在星地链路、星载链路、数据服务体系等方面构建了分层、开放的体系架构：其上行链路协议采用符合CCSDS遥控链路协议[4]，下行链路协议采用高级在轨系统(AOS)链路协议[5]，网络层采用空间包协议[6]进行数据包转发，应用支持层采用包应用标准(PUS)服务进行通用化设计。在这些通用协议的基础之上，本文提出了基于软总线的任务交互技术，使得任务与任务之间解耦合，方便软件任务模块拆分和重组；提出了硬件抽象和设备虚拟化技术屏蔽底层硬件和操作系统差异，从而实现该软件架构在遥感和其他领域不同卫星硬件环境下移植。本文描述的开放式分层星载软件架构已在测绘、对地观测、海洋观察和在轨维护等多个领域20多颗卫星应用，其中高分多模卫星(GFDM-1)等8颗卫星已经发射在轨，本文对其在轨验证情况进行分析和总结。

1 传统遥感卫星数管软件体系结构

传统遥感卫星中，数据系统软件一般以进程的形式分为多个模块。进程之间一般以消息通信和全局变量的方式进行交互，尤其是后者。每个功能模块一般直接操作应用层、网络层到底层硬件。以遥测功能为例[7-9]，如图1所示。

图1 传统遥感卫星平台软件遥测模块处理流程和结构Fig.1 TM module process and structure of satellite software based on traditional satellite

从第0个时间片到第5个时间片处理的业务可以看出，该体系结构是按照业务流程划分，每个业务流程完成从底层1553B总线控制芯片获取遥测数据，再到上层数据处理、链路层网络层业务逻辑组包，再到底层遥测硬件操控输出的全过程都在一个模块(遥测模块)中。由于每个卫星软件、功能模块的开发，其底层协议和硬件操作都各自不同，需重新开发，导致业务逻辑和硬件进行绑定，软件架构难以适应不同卫星的硬件环境。

2 中型敏捷遥感卫星公用平台开放式分层体系软件架构

2.1 总体架构设计

为了将业务与逻辑结构、软件与硬件解耦，提升逻辑代码通用性和软件架构跨硬件平台适应性，本文提出了包含应用层、软总线(星内路由)层、中间件与构件层、设备虚拟层和硬件层5个层次的开放式分层体系星载软件架构，如图2所示。

图2 五层开放式分层星载软件架构Fig.2 Five-layer open hierarchical on-board software architecture

在本文提出的架构中，应用层各进程间隔离，软总线层、中间件与构件层实现跨卫星完整复用，通过设备虚拟层实现跨硬件移植。本章后续小节将分别对应用层、软总线(星内路由)层、中间件与构件层的设计进行描述；硬件抽象与设备虚拟化层是本文提出实现软件架构跨卫星硬件移植的关键技术，将单独采用第3章对该层的设计和实现方法进行描述。

2.2 应用层设计

该层直接面向用户需求，实现了与需求相关的各个功能。一般来说包括系统自检、总线管理、电源管理、自主任务管理、载荷管理、指令管理、故障隔离与检测等常规功能。为了实现这部分功能的通用化，该架构参考ECSS标准体系的包应用标准(PUS)，形成通用化的“新一代卫星软件常规功能”，通过参数配置的方式以适应多个不同的遥感卫星需求。针对具体的遥感卫星，该软件架构增加了姿态轨道计算、单性任务协同、快速轨道预报、星上自主健康等功能，用于支持卫星自身特殊空间任务，以及提升智能化和好用易用性。

应用层各个功能模块以多进程的方式实现，各个进程之间不存在直接的调用关系，通过软总线(星内路由)，以标准化数据接口驱动的方式实现各模块之间的交互，以降低进程间的耦合，保持各个模块的独立性。

2.3 软总线(星内路由)设计

软总线(星内路由)主要负责将各进程、星内各终端的数据流转，从而使得各进程之间通过标准的数据接口进行交互，而不像传统卫星软件架构一样发生逻辑层调用关系，如图3所示。软总线对上层进程提供标准的数据接口，并且调用下层AOS链路协议、遥控链路协议、操作系统消息队列和时间同步15553B协议相关程序进行数据分发和接收，从而使得上层应用程序与底层链路协议解耦，便于软件移植。

图3 路由/软总线和其他进程拓扑结构Fig.3 Topology among Router/SoftBus and other Process

2.4 中间件与构件层设计

中间件与构件层封装并复用大量逻辑操作。本层各个模块必须严格保证是独立存在的个体(具体来说就是能够独立编译)，其向上提供应用接口并隐藏自身细节，以提供其他应用进程使用，其具体结构见文献[10]。

本文所述的软件架构设计了智能任务规划算法库构件群、指令序列调度构件群、缓存管理构件群、遥测数据池、基础算法库构件群、星内子网链路构件群等37类构件群，从而大力支持上层业务逻辑复用。

3 硬件抽象与设备虚拟化层设计和实现

为了屏蔽硬件的差异带来上层软件的差异扩散，需抽象出标准的硬件驱动对外接口，包括统一的操作接口和数据接口，这种位于硬件设备之上、数据链路层之下的接口称为“软”设备。软件产品将建立在统一的设备驱动之上，并通过软仿真技术对自动生成的软件功能、性能进行仿真。

3.1 设备虚拟化层设计

3.1.1 “软”设备的内部结构

对星载软件常用的硬件接口进行抽象，提炼出每种接口通用的控制逻辑和数据缓存，形成每种接口的“软”设备，其结构描述如下。

(1)控制逻辑。控制逻辑部分一方面完成“软”设备对底层硬件的控制，并从底层硬件获取硬件状态信号，另一方面控制“软”设备的存储区地址访问过程，并获取存储区的地址状态。

(2)数据缓存。数据缓存在控制逻辑的控制下，存储来自上层软件的需要输出的数据或来自底层硬件的需要输入的数据，并返回数据缓存的状态。

3.1.2 “软”设备和上层软件之间的数据传输关系

“软”设备的设计也是基于构件化和层次化的综合电子软件体系思路的，每个“软”设备为一个独立的软件单元，上层软件需要访问底层硬件时，调用相应“软”设备的接口函数，完成数据在软件和底层硬件接口之间的传输。“软”设备和上层软件之间的数据传输关系见图4。

图4 “软”设备和上层软件的数据传输关系Fig.4 Data transmission relationship between virtual device and upper software

3.1.3 “软”设备和上层应用软件的通信过程

1)数据输出流程

(1)上层软件完成航天器数据处理，生成满足“软”设备输出要求的数据格式。

(2)上层软件调用“软”设备的状态接口函数，判断当前该“软”设备是否为空闲，如果为空闲则进入下一步，如果为忙则继续等待。

(3)上层软件调用“软”设备的传输接口函数，将航天器数据传输给“软”设备。

(4)“软”设备访问底层硬件接口，将数据输出。

2)数据输入过程

分为两种情况，第一种情况由上层软件主动发起，按照预期的时序关系控制“软”设备获取需要的数据，第二种情况为上层软件查询“软”设备是否接收数据，并根据查询状态从“软”设备获取数据。

(1)第一种情况的输入流程：①上层软件运行到数据接收时隙；②上层软件调用“软”设备的状态接口函数，通知“软”设备控制底层硬件采集数据；③上层软件等待“软”设备采集结束的时隙，调用“软”设备的传输接口函数，从“软”设备读入数据。

(2)第二种情况的输入流程：①上层软件调用“软”设备的状态接口函数，查询“软”设备是否接收到数据；②如果“软”设备状态为接收到数据，则上层软件从“软”设备读入数据。如果“软”设备状态为尚未接收到数据，则上层软件继续查询；③底层硬件接收到数据(比如上行遥控数据)时通过中断通知“软”设备获取数据。

3.2 硬件抽象与设备虚拟化实现

本文将实现跨卫星硬件平台移植的关键技术——硬件抽象与设备虚拟化技术的一些关键点的设计与实现进行描述。

依据本项目的设计，硬件接口相关的处理函数都属于硬件抽象与虚拟化层。硬件抽象与设备虚拟化层完成对硬件接口的二次封装，从而保证当硬件设备发生变化时，上层不需要根据硬件设备的变更情况进行任何接口相关的修改。

3.2.1 存储器设备虚拟实现

以高分二号卫星(GF-2)为例，大多数传统遥感卫星使用的是带电可擦写可编程只读存储器(EEPROM)，以高分多模卫星为代表的新一代遥感卫星使用了闪存(FLASH)存储器。为了将高分多模卫星的软件移植到其他卫星，只需要修改硬件抽象与设备虚拟层的存储器驱动程序，添加相应的FLASH操作接口即可。

1)定义并实现存储器设备操作函数

FLASH操作除了读写方法不一样，比EEPROM多了擦除操作。为保持一致，EEPROM的接口也要留一个空的擦除操作接口。

最终，FLASH和EEPROM的读写操作函数如表1所示。

表1 存储设备虚拟化操作函数列表Table 1 Operate Function List of Storage device virtualization

2)配置虚拟设备接口函数

存储器虚拟设备接口函数采用统一的读写擦做，即PromRead和PromWrite，通过参数配置和函数绑定的方式，使得PromRead和PromWrite调用表1中不同的操作函数，从而实现虚拟设备接口统一化，上层软件进行存储器访问时调用下层设备，无需关注存储器设备硬件细节，进而实现存储器设备虚拟化。

3.2.2 总线传输设备虚拟实现

以GF-2、嫦娥五号(CE-5)和GFDM-1等卫星为例，以上3种硬件平台都采用了1553B总线进行设备间的通信。为了提高总线通信效率，本软件架构参考ECSS相关国际标准[11]，提出了基于时间同步的1553B总线通信技术和对应的协议[12]。对此，在本架构中在进行1553B处理跨硬件移植时，所进行的修改包括以下几部分内容。

1)创建设备接口

首先补充定义了1553B总线的设备结构体bus_1553B_struct，其中包含的关键字段包括： 1553B总线的寄存器基地址、1553B总线的RAM基地址、1553B总线数据存储相关信息、1553B总线各项操作对应的在轨维护函数指针。

其次在构件初始化接口函数中，完成对1553B总线设备结构体的创建与初始化操作，其中具体操作包括各项关键字段的定义，以及在轨维护函数指针的挂接操作。

2)配置设备接口函数

由于声明了设备结构体，因此在定义新的修改设备接口函数时，需要通过设备结构体内的关键字段进行数据交换。接口的配置方法同存储器硬件虚拟配置部分的内容，即通过函数指针完成对设备接口函数的挂接。

3.2.3 遥测/遥控硬件虚拟配置实现

与总线芯片虚拟配置的原理相同，在标准化星载软件框架中，首先定义遥测或遥控模块相对应的设备结构体。随后，完成相应处理函数与面向应用层的接口函数的绑定工作。应用层通过声明的设备结构体对象中的接口函数，即可完成遥测或遥控硬件的操作。

表2给出了遥测硬件虚拟配置中的关键参数和关键接口。

表2 遥测硬件虚拟化关键参数和关键接口Table 2 Key parameters and interfaces list of telemetry device virtualization

3.2.4 其他硬件设备虚拟化

卫星综合处理单元除了以上硬件设备，还可能包括CPU、时间管理芯片、内总线、指令译码等硬件模块，其设备虚拟化方法与上述硬件抽象与设备虚拟配置的原理相同，即首先定义模块相对应的设备虚拟结构体，其次完成相应处理模块的设计，最后完成面向应用层的通用化接口函数的设计，并与对应逻辑处理模块绑定。由于篇幅原因，不再展开说明。

4 结束语

经过“十三五”期间多颗卫星的实践，本文提出的开放式分层软件架构已经在测绘、对地观测、海洋观察等遥感和在轨维护等多个领域得到应用和验证。基本情况如下。

(1)本软件架构在高分十一号01卫星、高分十一号02卫星、高分十三号卫星、高分十四号卫星、新技术验证六号01卫星、新技术验证六号02卫星、新技术验证七号卫星、高分多模卫星等9颗卫星在轨飞行验证，基于该软件架构实现的数管和综合电子分系统软件运行良好，卫星各项任务个管理功能运行顺畅，软件架构在轨可靠性得到充分验证确认。

(2)本软件架构同时应用于多颗在研卫星，采用该架构之后，多个卫星之间采用通用化设计，卫星数据管理或综合电子系统软件复用率(逻辑函数或源文件级完整复用)由5%～10%[9]增长至70%～87%。

(3)本软件架构提出了硬件抽象与设备虚拟化技术，将软件与硬件解耦，从而使得仅需要修改与硬件的最底层接口，即可支持多个卫星甚至多种平台，跨硬件移植代码修改量由3000行以上缩小至200行以内，效率提升10～15倍。

总之，基于中型敏捷遥感卫星公用平台开发的、与国际标准接轨的遥感卫星数据系统开放式分层体系架构所实现的星载软件，自2018年7月以来已经过多颗在轨卫星的应用和验证。它实现了不同卫星应用中任务与任务之间的解耦，业务与逻辑结构、软件与硬件的解耦，提升了逻辑代码通用性和软件架构跨硬件平台的适应性，从而为实现系统软件在不同领域遥感卫星硬件环境下的移植奠定了基础。