一种基于文件的嵌入式星载软件在轨升级方法

2018-05-16，，

单片机与嵌入式系统应用 2018年5期

，，

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

引言

随着航天器寿命的增长和任务难度的加大，星载软件的复杂度越来越高，需要具备在轨重构和更新能力，以应对可能出现的任务扩展和软件潜在缺陷[1]。星载软件在轨维护是指地球站对航天器在轨飞行过程中所碰到的困难，包括飞行软件在飞行过程中暴露缺陷的纠正。

星载软件通常固化在只读存储器中，只具备有限的RAM区数据在轨维护能力[2]，部分高轨长寿命航天器设计了独立在轨维护模式[3]，在处理器8位模式下，将上注的新程序写到RAM区实现软件整体升级维护。由于只能在RAM区进行数据更改，以上在轨维护方法存在掉电丢失的问题，并且在软件整体升级过程中，星载系统处于在轨维护模式，不具备整星服务功能，存在潜在风险。

为实现星载软件持久化的在轨维护，需要使用在线可编程器件，常用的有EEPROM和FLASH。参考文献[4]提出了在可编程存储器条件下基于VxWorks操作系统的在轨维护方案，可实现VxWorks下的目标码持久化维护，但不具有通用性。参考文献[5]提出了基于增量链接的星载软件在轨更新方法，可实现通用系统下星载软件的在轨维护操作，对空间环境中存储器异常状态下软件升级问题以及星载软件配置数据重构问题缺少考虑。

本文分析了近年来星载软件在轨维护案例，提出了一种基于文件系统的星载软件在轨维护方法，实现软件映像可靠存储、程序和配置数据分离、软件整体升级可回退以及程序局部维护持久化，为长寿命航天器软件在轨维护策略提供了参考。

1 星载软件在轨维护特点分析

不同于一般的地面系统软件，星载软件在轨维护具有较多的条件限制：星地测控时段短，通信速率小，要求在轨维护必须在有限的时间内完成；空间环境复杂，星载软件可靠性要求高，需要应对可编程存储器部分存储单元数据反转或失效的风险；关键星载软件负责整星平台热控、电源等关键业务，要减少在轨维护期间系统服务的停止时间，维护失败时应能及时回退到以前的版本。

表1列出了近年国内遥感卫星数管分系统软件在轨维护的情况。测控圈次需求是依据在轨维护补丁数量和一个圈次内测控站能上注的指令条数计算而得。假设一次地面站测控8 min，每5 m上注一条在轨维护指令。

表1 星载软件在轨维护案例

通过上表可以看出，星载软件在轨维护的原因主要是设备参数调试优化和故障处理；软件配置数据的更改占据在轨维护的大部分项目；多数在轨维护的补丁较少，能在一次地面站测控区内完成，但软件整体维护的补丁较多，需要多次地面站测控上注。

2 基于文件系统的在轨维护方法

2.1 软件结构划分

针对星载软件在轨维护特点，提出了基于文件系统的星载软件在轨维护方法。如图1所示，星载软件系统由引导软件、文件系统、应用软件映像文件、配置数据文件和补丁文件组成。其中应用软件、配置数据文件和补丁文件存在文件系统中。在此软件结构划分下，星载软件在轨维护分为软件整体升级、配置数据重构和程序局部维护三类。

图1 基于文件系统的星载软件系统结构

引导软件映像直接存储在存储器中，系统上电后最先运行，完成系统初始化，加载文件系统，从文件系统中读取引导配置项，选择加载的应用软件映像，加载执行补丁文件，完成应用软件的启动。

由于引导软件是系统的入口程序，直接存储在存储器上，没有冗余存储措施，任何存储单元的损坏都会导致系统失效，同时引导软件功能固定，几乎不需要在轨维护，因此引导软件应固化在可靠性高的只读存储器中。

文件系统是存储维护应用软件映像、配置数据和补丁数据的载体。文件系统可屏蔽底层可编程存储器的物理特性，提供高可靠的数据存储和维护服务。

配置数据文件保存了星载软件运行时所需要的参数信息，与星载应用软件程序分开存储管理，需要时不必修改软件逻辑功能，仅通过地面上注手段在轨修改配置数据文件，可实时在航天器正常运行状态下对信息流进行动态重构。

星载软件映像文件是星载软件的主体部分，被引导软件搬移到RAM区运行。星载软件映像一般比较大，采用压缩存储的方式[6]，可显著减少在轨维护时上注数据的时间。

补丁文件存储了内存修改指令，在应用软件映像搬移到RAM后，执行内存修改指令可以修改RAM的程序代码，实现局部软件持久化更新。

2.2 文件系统设计

本方法中，所有的在轨维护操作均以修改文件系统中文件的形式实现，因此文件系统的存储结构和可靠性非常重要。常见的嵌入式文件系统包括JFFS2、ROMFS和znFAT等。

JFFS2使用日志技术保证了文件在线更新过程中元数据的一致性[7]，但是实现复杂，需要在RAM中重新建立文件系统结构本身，挂载时间长，需要的内存资源大，不适合应用在计算资源有限的星载设备系统上。

ROMFS是只读文件系统，文件以线性结构顺序存储在存储器中，支持目录文件和符号链接，需要更新文件时，只能对整个文件系统进行修改，不符合星载软件在轨维护需要减少数据上注量的要求。

znFAT是在FAT32 基础上优化的文件系统，znFAT 超级块中不仅记录着存储设备的类型、容量，还包括文件系统的卷标、保留空间、每簇(文件系统存储单位)大小、文件分配表个数和大小等重要参数；文件/目录项用来记录文件和目录的相关信息，类似于“索引”，可以通过信息查询找到数据开始的位置；FAT表记录了所有数据的链表式关系，通过FAT表可以查询到数据存储链表，找到完整的数据。znFAT实现简单，增加了数据校验和三模冗余功能，提高了数据的可靠性[8]，适合应用在星载软件系统中。

2.3 星载应用软件整体升级

图2 引导配置文件数据结构

采用文件系统存储管理数据，可在星上存储多份星载应用软件映像，由引导软件根据引导配置文件数据选择加载需要的应用软件映像。星载软件需要进行在轨整体升级时，在原应用软件运行的状态下，接收地面上注的指令，在文件系统中创建保存新的星载软件映像文件，修改引导配置文件，指示引导软件下次启动新版本的软件映像。

星载计算机开始运行后，引导软件读取引导配置文件，获取应用软件引导配置项，选择默认的应用软件版本进行加载。引导配置文件的结构如图2所示，包含默认引导配置项索引和引导配置项列表。每个引导配置项包括需要加载的应用软件映像名称、应用软件映像是否压缩标识、搬移到RAM区地址、搬移后长度、入口地址以及搬移后数据校验和。默认引导配置项索引指示默认加载引导配置项列表中的第几项。

引导软件加载应用程序流程如图3所示。引导软件根据引导配置文件将相应的应用软件映像解压或直接搬运到对应的RAM区，进行数据校验，如果引导软件在搬移应用软件映像后发现校验数据不正确，则选择引导配置列表中前一项尝试进行加载。加载正常后，读取补丁文件，获取需要执行的补丁指令，将补丁数据修改到对应的RAM区，完成应用软件的搬移和修改操作，最后跳到RAM区应用软件入口位置处运行。当所有应用软件校验异常或文件系统加载失败时，引导软件还需要完成基本的遥控遥测功能，从地面接收指令，修改RAM区数据，完成应用软件在RAM中的运行维护，在该模式下与现有的在轨维护操作类似，但只用在存储器严重损坏、文件系统崩溃的极端情况。

图3 引导软件加载应用程序流程

2.4 配置数据重构

配置数据修改是星载软件在轨维护的一项重要内容，通过使用文件系统配置数据与应用程序分离存储。需要时不必修改软件逻辑功能，仅通过地面上注手段在轨修改配置信息文件，可实现在航天器正常运行状态下对信息流进行动态重构。

星载软件初始化时，需要挂载文件系统，通过文件名称获取配置数据内容。对于系统在运行中需要频繁使用的一些配置数据，为避免每次从文件系统中读取数据耗费时间，在内存中申请缓冲区保存从文件中读取的数据，同时可能还需要根据配置数据组织运行时的数据结构。当航天器状态发生变化，需求更新配置参数时，通过上注修改配置数据文件，星载软件运行时使用的数据可能没有更新，需要通过进行局部的数据初始化完成实时信息重构。当星载软件再次重新运行进行初始化时，使用的配置数据即为新的内容。

2.5 程序局部维护

为避免软件整体升级上注数据时间过长，采用在程序加载时自动打补丁的方式进行程序局部维护。补丁文件存储了内存修改指令，与传统的在轨维护指令类似[9]，用于改写指定内存区的数据。通过在空白区注入新的指令代码，将旧代码区的函数调用引向新代码的方式，实现程序区的局部代码更新。

传统的在轨维护指令在星载软件运行时接收执行，作用范围受限，某些系统初始化过程中一次性执行的代码无法通过该方式修改，并且系统复位重启后需要地面重新上注。本方法采用在引导软件加载应用程序后执行内存修改指令，实现了修改范围的全覆盖以及补丁的持久保存。

由于补丁是直接修改内存中的代码映像数据，一般针对某个特定的应用软件版本，所以补丁需要与特定的软件版本绑定。当引导软件完成应用软件映像加载后，找到该映像名称对应文件夹下的所有补丁文件执行内存修改操作。

3 试验验证

基于某遥感型号星载计算机平台测试环境[10]，对所提出的星载软件在轨维护方案进行试验，主要针对补丁大小、更新操作执行情况和异常情况进行测试。

3.1 更新操作试验

原始版本应用软件逻辑程序目标代码为150 KB，压缩后为72 KB，配置数据文件大小为10 KB。进行3次修改，分别修改配置数据、程序局部修改和软件映像整体升级。表2显示了软件维护的试验结果，包括修改文件数量、修改内容以及补丁大小。试验结果表明，该方法的维护操作正确，更新结果能持久化保存，配置参数维护和局部维护的补丁数量远小于整体升级的补丁数量，整体升级补丁小于目标码大小。