系列研究 | NASA软件参考架构

在软件架构方面，GSFC的核心飞行系统(Core Flight System, CFS)软件以其开放性、通用性等特征，在NASA各中心逐步获得广泛应用。

CFS是GSFC应用推广在总结其飞行软件经验的基础上，于2005年启动的一个开源软件项目，旨在提供一套通用的飞行软件服务框架，避免重复开发，使得软件开发人员专注于任务相关的功能部分，提高效率，降低成本。目前已经在GSFC，JSC，ARC和APL等中心十数个任务中得到应用。

核心飞行系统(CFS)包括核心飞行执行机构(core Flight Executive, cFE)，CFS库和CFS应用等内容，其中核心飞行执行机构(cFE)是其功能核心，提供飞行软件的基础服务平台，包括执行服务(Executive Services)、事件服务(Event Service)、软件总线(Software Bus)、表服务（Table Service）和时间服务(Time Service)。

l 执行服务：管理核心执行机构启动、重启等控制，处理关键数据内容，提供系统监控和分析等功能；

l 事件服务：提供遥测异步信息/错误消息发送接口，支持信息过滤功能；

l 软件总线：提供应用之间的消息通路接口，报告通信错误和反馈统计数据；

l 表服务：管理飞行系统数据和信息，提供统一接口；

l 时间服务：提供时间服务，包括飞行器时间与地面时间关系、飞行持续时间等。

此外，GSFC还开发了操作系统抽象层(OS Abstraction Layer, OSAL)软件作为核心飞行系统与操作系统的中间层，隔离不同操作系统的接口差异，保证核心飞行系统的通用性。

历史演进

在GSFC早期的任务中，软件复用的比例也非常低，大部分任务遵循的是“复制+修改”的方式，即在前序任务的代码基础上进行修改以适应新的任务。但是这种模式具有明显的缺点：

l 新的硬件或者操作系统的引入，将导致飞行软件整体大幅度的变动；

l 飞行软件需求可能进行了重写，导致软件的开发和测试必须从头开始；

l 软件代码的修改内容取决于开发者的能力；

软件架构评审结果

2011年至2012年，NASA 软件架构评审委员会组织喷气推进实验(JPL)，兰利研究中心(LaRC)，约翰逊空间中心(JSC)，马歇尔空间飞行中心(MSFC)，应用物理实验室(APL)以及相关大学等机构对核心飞行系统进行审查，得出以下结论：

l 覆盖性：系统满足NASA大部分任务应用，可以成为NASA飞行软件统一架构框架；

l 应用潜力：各中心评审专家认为该结构非常成熟，易于集成和测试；能够增强各中心之间的合作；作为开源项目，非常适合大学研究；

l 架构性：委员会对架构提出高度评价，认为将对应用开发产生深刻影响，特别是软件总线、操作系统抽象层等功能具有显著特色；

l 文档组织：委员会认为当前文档需要进一步完善，在需求和设计描述方面未考虑更大范围使用需要。

2012年起，GSFC根据评审委员会的意见对系统进行改进，包括支持多核、分布式环境等。此外，约翰逊空间中心，应用物理实验室，肯尼迪飞行中心等多个机构在评审后决定在新的任务中采用核心飞行系统软件。以下是评审的详细内容。

评审成员

•  Michael Aguilar (NESC, NASA Software Discipline Expert)

•  Dan Dvorak (JPL, SARB Lead)

•  Lorraine Fesq (JPL, review chair)

•  Robyn Lutz (Iowa State University)

•  Michael Madden (LaRC)

•  Pedro Martinez (JSC)

•  Alex Murray (JPL)

•  John Weir (MSFC)

•  Steve Williams (APL)

评审结果

CFS应用推广

2014年戈达德飞行中心开源cfs，并成立了专门的开发者社区，联系NASA各中心以及世界各国用户共同推动CFS的发展。

由于cFS的用户逐渐增多，从2014年起，NASA每年都有一天举办专门的讨论。在2015年，与飞行软件年度论坛合并，直到目前可见的2018年年会，每年都有一天cfs的主题日，由GSFC和广大用户就开发和应用现状进行交流。

2009年《NASA飞行软件复杂度研究报告》提到的另一个可能的参考架构是JPL的任务系统架构平台（Mission System Architecture Platform）。

NASA JPL虽然也在部分任务中采用GSFC的cfs，但是大部分任务独自构建管理着一套独立的飞行软件架构。2013年，JPL的Kathryn Weiss在飞行软件年会FSW上以《An Introduction to the JPL Flight Software Product Line》为题介绍了其做法，并在2014年FSW的Architecture panel中再次介绍同样内容。软件产品线的内涵要大于软件架构，其还包括飞行软件的组织结构和开发环境等。

概述

JPL的软件开发也曾经是基于各个任务而开发，由紧耦合的模块构成的难以复用的产品。从火星探路者号(1997)开始，后续各个火星探测器遵循“复制而修改”的模式，即每一个新的任务，其软件都基于前续火星探测器的代码进行修改。

2013年JPL提出软件产品线的开发理念，其主要目标包括：

l 提供一套完整的航天电子系统和飞行软件产品；

l 提高飞行软件的可重用性，充分发挥历史资产的价值；

l 减少新任务飞行软件的开发时间和成本；

l 在保证可靠性的前提下，提高飞行软件技术演进的能力；

l 利用统一的开发框架，支持分布式的开发和交付。

JPL的软件产品线概念包括三方面的内涵，分别是：

（1） 一系列可重用的飞行软件资产库；

（2） 飞行软件产品的开发策略，包括架构指南和接口规范；

（3） 一套管理方法，由产品线的管理部门负责的使用、部署、维护和演进。

JPL的软件产品线由其编号为349的飞行电子系统与软件部门负责开发、维护和推广应用。部门349的组织架构如下：

在部门349，新增了3个技术团队负责软件产品线的工作，分别是核心飞行软件组，小规模飞行软件组和大规模飞行软件组。其中核心飞行软件组负责软件产品线的开发和维护，两个大小规模飞行软件组负责软件产品线在不同任务中的推广应用。

软件产品线包含一系列模块化的独立单元，并对安全关键模块和非安全关键的模块进行明确划分，提高灵活性和可重用性的同时保证可靠性。

软件产品线的内容包含三个层次，分别是功能层，活动层和行为层。

功能层：为实现飞行软件目标而定义的一系列离散动作；

活动层：为实现飞行软件目标而定义的按序列执行的一系列函数，有行为层或地面控制启动；

行为层：通过自动调用一系列活动层的函数完成任务目标。

上述设计与《NASA飞行软件复杂度研究报告》附录H的理念完全一致，而附录H的作者即JPL的Robert D. Rasmussen，他也是上述349部门的总工程师(Chief Engineer)。

核心产品

功能层包含很多软件模块单元，如设备管理，软件服务等，但是最核心的是飞行软件核心产品（FSW Core product）。

核心产品负责与底层硬件平台直接交互，为其他模块提供服务.如图所示，核心产品包含三个层次：

(1) 最底层是平台抽象层，包括平台接口软件（SUROM，BSP，ADP），实时操作系统（Vxworks 6.7， Vxwork6.7 RTPs, Vxworks 653等），设备驱动，核心OS等。

(2) 平台抽象层之上是操作系统服务层，如消息，内存，时间，输入输出和其他工具（如数学函数，压缩，位操作）等；

(3) 最上层是飞行器服务层，包括配置管理，命令，遥测，参数，文件，健康管理等。

模块结构

模块之间的通信只能通过两种方式：（1）通过队列，多个发送者向接收者进行非阻塞的异步发送；（2）通过共享内存，单个发送者对接收者进行同步写

确定性状态机

每一个模块都是由确定性的状态机实现，从而保证完全可预测的行为，任何异常都可以从状态机的状态方便的推断原因。

初始化策略

所有模块之间都没有编译依赖，在运行时通过“注册”的方式建立运行环境。这种机制使得每个模块可以独立地进行更新，从而允许分布式的开发和交付。所有系统资源的分配，如内存，调度时间片，以及模块集合，都是在系统初始化时就完全确定。

这一点与Linux和QEMU等开源软件的设计理念很相似。

运行时架构

所有处于运行状态的线程，根据其实时性的需求进行调度；

实时线程根据系统初始化时设置的参数，按照固定时间片和顺序进行调度，保证系统的确定性执行；所有安全关键的任务都在实时线程中。

非实时线程则由系统进行全局性的动态调度；

健康管理

所有模块的状态都按照固定的模式进行变化，如设备功耗，故障监控等，从而保证系统按照确定性的行为运行。