开源微小卫星飞行软件框架比较分析
摘要
如今,纳米卫星任务正变得越来越流行,尤其是因为其成本降低。因此,由于纳米卫星引起的范式转变,许多组织正在进入太空领域。尽管这些航天器的尺寸减小了,但它们的飞行软件(FSW)的复杂性与卫星体积不成正比,因此为新玩家进入纳米卫星市场制造了巨大障碍。另一方面,有一些可用的框架可以提供成熟的FSW设计方法,这意味着软件项目的时间框架和成本大大减少。本文根据通常要求的“新航天”标准,对六种相关的飞行软件框架进行了比较,最后指出了最适合VCUB1参考纳米卫星任务的框架。
概述
飞行软件(FSW)是在嵌入航天器航空电子设备的处理器上运行的软件。它负责管理船上活动、数据处理和航天器健康与安全。
“飞行软件”的名称反映了其执行的位置,即在航天器中,以区别于在地面段运行的“地面软件”。它被认为是一个高风险系统,因为它直接与航天器硬件交互,以不同的自动化水平实时控制几乎所有的机载系统(Dvorak 2009)。在这样一个领域,由于发射后无法访问硬件,以及空间环境的固有特征,故障保护和恢复的水平通常高于通常的计算机系统。
在航天任务中,任务实现的责任由地面和空间部分共同承担。第一批太空任务将几乎所有任务分配给地面部分。在这些任务中,空间段仅仅是从地面发出的命令的执行者。通过将计算机添加到空间段,操作员可以开始将任务委托给船上执行(Kucinskis和Ferreira,2013年)。随着航天器机载计算机和电子设备的发展,以及对航天器自主运行的信心的增强,飞行软件承担了更多的责任。如今,任务越来越需要更强大、自主、健壮和灵活的飞行软件来满足复杂的任务需求。
尽管如此,艾克霍夫(2012)表示,对于航天领域的新进入者来说,机载计算机、飞行软件和操作设计通常是一个挑战,尤其是由于缺乏专门的文献。
另一方面,还有一些用于航天项目的开源框架。它们由航天机构、大学或航天公司创建,作为参考设计,并在未来的项目中促进代码重用。作为FSW开发的一个相对较新的选择,这些框架到目前为止还没有在其所在组织之外得到广泛采用。
从零开始一个FSW项目,特别是对于新的组织来说,可能是一项非常昂贵的工作。通常的软件系统开发通常得益于现有的软件开发工具包(SDK)、框架、设计模式和支持开发人员工作的不同工具。在航天器项目中,代码重用和框架使用并不是广泛传播的概念。
Schmidt et al.(2004)指出,使用成熟的软件框架会导致开发程序缩短,
降低了成本,提高了质量。这些后果对航天组织是有益的,这也是本次调查的动机。
根据纳米卫星参考任务软件选择标准,分析了六个相关的FSW框架。这个项目是“新航天”的典型代表。
该参考任务名为VCUB1,是巴西航天公司Visiona space Technology S.A.正在开发的一个在轨演示6U CubeSat。该CubeSat项目是一个典型的新太空项目:团队规模小、进度短、预算少、搭载发射、尽力而为的可靠性范例(几乎没有机载设备冗余,大多数设备没有rad硬保护),简化验证和确认(V&V)周期在单个航天器原型飞行单元上进行。
关于FSW,由于项目进度紧张和资源有限,从头开始设计不是一个可行的选择。它决定受益于现有的飞行验证FSW框架,作为设计范例。
相关工作
对于航天器使用的框架,很少有比较。其中一个由Rexroat(2014)提出。他比较了几种候选中间件,目标是分布式嵌入式系统,即无人机(UAV)和立方体卫星。然而,作者不仅考虑了服务级别的中间件,还考虑了网络(如SpaceWire)和分发层(如MIL-STD-1553)级别的较低级别的中间件。
Rexroat的一些选择标准是:
网络通信——面向节点的系统与面向消息的系统
协调——同步与异步行为
可靠性——就信息传递而言:最多一次、至少一次、恰好一次
可扩展性——在以下方面进行抽象:访问、定位、迁移和复制
异构性——不同硬件、网络或软件的可移植性和互操作性
MAVLink最初是为无人机世界开发的,是他为无人机和立方体卫星选择的中间件解决方案,NASA核心飞行系统(cFS)排名第二。
与Rexroat不同,目前的工作侧重于纳米卫星任务的软件设计方面,而不是网络方面。
“新航天”和VCUB1任务
过去几年,私营部门更多地参与全球航天活动所造成的变化被称为“新航天”(Paikowsky 2017)。这一术语与“旧航天”相反,即自航天活动开始以来的现有生态系统,其特点是主要由国家活动控制,且主要是国有企业。
在新的航天背景下,卫星的技术小型化使开发和发射卫星的成本得以降低。客户和投资者都是私人参与者,这一事实导致金融模式从成本加成转向固定价格。这种变化需要不同的管理方法,并要求投入研发(R&D)的时间更短。卫星、系统和组件现在可以现货购买,卫星在轨道上的时间相对较少。因此,项目管理更倾向于承担风险,在服役期间进行技术演示,通常不以在轨道上100%成功为目标,就像“旧航天”生态系统下的卫星开发一样(Paikowsky 2017)。
新太空最成功的成果之一是立方体卫星。CubeSat概念于2000年公开提出,第一批CubeSat于2003年推出(Swartwout
2013)。立方体卫星是围绕基本体积单位10厘米×10厘米×10厘米(定义为1U)的倍数开发的小型长方体卫星。
由于CubeSat分配器或部署器的标准化工作,CubeSat开辟了更快、更便宜的任务机会,这正逐渐被多个发射机构接受为二级有效载荷(Chin等人,2008年)。
VCUB1参考任务是巴西航天公司Visiona space正在开发的6U立方体卫星演示
Technology S.A.预计目标发射日期为2020年。
航天器包含两个有效载荷。一种是多光谱光学相机,专门用于遥感。第二个是基于FPGA的数据采集无线电,允许双向窄带数据通信。该卫星将被放置在低轨太阳同步轨道上,平均每天经过巴西3次(Conto等人,2018年)。
该任务的目标是低成本、固定价格,主要使用商用现货(COTS)零件。它是构想出来的
作为在轨道上验证某公司软件技术的研发项目。因此,项目管理理念愿意接受一些风险。该卫星将作为二级有效载荷发射,易受CubeSat发射机会的影响。因此,这是一个遵循CubeSat标准的典型新航天任务。
关于任务FSW,低成本、短进度的前提条件和尽力而为的可靠性范例促使团队寻找与CubeSat
COTS车载计算机(OBC)兼容的成熟开源FSW框架。
参考任务软件选择标准
表1总结了飞行软件框架选择的标准,即:
1. 软件代码和文档,
2. 飞行遗产,
3. 占用空间小
4. 质量属性
5. 长期支持
6. 用户社区协作和
7. 航天数据系统标准化协商委员会标准。
标准1至3来自参考任务的高级要求。然而,这些都是太空任务的典型要求,尤其是在新的太空模式下。
质量属性(标准4)的灵感来自Wilmot等人(2016)。并不是所有的14个质量属性都被识别
NASA的软件架构审查委员会(Software
Architecture Review Board)只采纳了与软件实现更密切相关的内容。除了这些质量属性之外,它还添加了正式的规范和定义良好的语义,这是一些框架文档的启发。
标准5至7的目的是评估框架在各种任务(用户-社区协作)和标准化可能性(CCSDS)基础上发展和改进的能力,所有这些都由其赞助/维护机构执行(长期支持)。
表1。FSW选择标准。
Criteria | Description | |
1 | Software code and documentation | |
1.1 | Open-source | 软件源代码和相应的文档可在internet开放代码存储库中免费获得,最好具有版本控制 |
1.2 | Technical documentation | 提供软件用户指南和全面的技术文档 |
1.3 | Demo/training | 提供有关如何使用框架的培训和见解的演示应用程序。SDK的提供被视为一种资产 |
2 | Flight heritage | 在以前的航天器或仪器任务中成功飞行的飞行软件框架 |
3 | Small footprint | 最小的内存和CPU使用负载 |
4 | Quality attributes | |
4.1 | Reliability | 软件代码的可靠性取决于是否存在具有显著代码覆盖率的单元测试 |
4.2 | Formal specification | 使用架构规则或需求来正式指定软件实现 |
4.3 | Well-defined semantics | 明确定义的行为的存在 |
4.4 | Requirements traceability | 需求可单独追溯到其实施和验证证据 |
4.5 | (component-based design) | 强调通过松散耦合的独立软件组件或应用程序分离关注点的飞行软件体系结构。它有利于软件代码的可重用性 |
4.6 | Portability (to several RTOS and processors) | 体系结构和应用程序的设计和实现属性,支持它们在初始目标系统以外的系统上的使用。它通常涉及软件隔离和抽象技术 |
5 | Long-term support | 根据赞助/维护机构战略计划,保证长期的框架软件支持 |
6 | User-community collaboration | 用户返回在集中的internet开放代码库中表达的体验。具有普遍开放门票发行、分叉和上传软件代码的能力,所有这些都由赞助机构控制和调节 |
7 | CCSDS standardization | 该框架已被主管当局(在本例中为CCSDS)确认为表达性框架,并被标准化为参考飞行软件体系结构 |
飞行软件框架
有一些软件框架的目标是在航天项目中标准化、模块化并将应用层与较低层分离。对文献进行了回顾,以找到一组具有代表性的这些体系结构及其特征。将分析六种最先进的框架,以选择在纳米卫星参考任务中采用哪一种。
GERICOS
GEneRIC 机载软件 (GERICOS) 框架由法国空间研究实验室 LESIA (Laboratoire d’Études Spatiales et d’Instrumentation en Astrophysique) 开发和认证,用于快速开发有效载荷飞行软件。
GERICOS 研究始于 2007 年。当时没有现成的软件解决方案可用。 2015 年底,使用 GERICOS 框架(Plasson et al. 2016)交付、构建和认证无线电等离子波仪器飞行软件。该仪器将在欧空局的太阳轨道飞行器任务中飞行,预计将于 2020 年发射。
GERICOS 框架提供了一组可重用和可定制的飞行软件组件,用C++ 编写。它由3层组成,如图1所示:
GERICOS::CORE:在实时内核之上的活动对象范例的轻量级优化实现。
它包括与实时和嵌入式系统相关的概念,例如中断、同步对象、共享资源和循环缓冲区。该层允许开发人员使用面向对象的方法快速构建实时应用程序,同时独立于特定的实时操作系统和特定的硬件目标。每个活动对象都有自己的消息队列和计算线程。
GERICOS::BLOCKS:提供一组可重复使用的软件组件,用于构建基于通用解决方案的飞行软件,以实现经常性功能:遥控管理、遥测管理、一些欧洲空间标准化协调 (ECSS) 数据包利用标准 (PUS) 服务,模式管理、时间管理、CCSDS协议管理等
GERICOS::DRIVERS:实现与芯片中使用的COTS IP 核相对应的软件驱动程序。
LESIA 正在努力使其他组织使用 GERICOS 框架成为可能。 GERICOS::CORE 已经完成的一项演变是其移植到 ARM 处理器,这允许 GERICOS 在 CubeSats 环境中使用,正如 2018 年 1 月启动的PicSat 任务所做的那样(Lapeyrere 等人,2017年)。然而,代码尚未开源,因此无法对框架架构进行更详细的分析。
图 1. GERICOS 软件层(Plasson et al. 2016)。
美国国家航空航天局 CFS
核心飞行系统 (cFS) 平台是由 NASA 戈达德太空飞行中心 (GSFC) 开发的三层飞行软件架构。 它提供了一个独立于操作系统和硬件的应用程序运行时环境。 cFS 最初是作为 NASA B 级软件开发的,用于 GSFC 科学任务,基于成功任务的传统。 它由三层组成,如图2所示,从下到上:
抽象库层,包括:
操作系统抽象层(OSAL):将飞行软件与实时操作系统隔离的小型软件库
平台支持包 (PSP):使 cFE 内核适应特定处理器架构所需的软件
cFE 核心层,包括:
执行服务 (ES):管理 cFE 核心和 cFS应用程序
事件服务 (EVS):提供用于发送异步调试、信息或错误消息遥测的接口
软件总线(SB):提供可移植的应用程序间消息服务
表服务 (TBL):管理所有 cFS 表映像
时间服务(TIME):管理航天器内部时间并将音调信号分配给查询应用程序
任务和cFS 应用程序层:由可重用和特定任务的应用程序组成。 NASA 目前有 13 个以开源形式分发的 cFS 应用程序(NASA 2017),它们实现了常见的航天器功能。 此外,新任务必须通过 cFS 应用程序定义和实施其特定于任务的功能。
图 2. NASA cFS 软件层和组件。 资料来源:美国国家航空航天局,2014 年。
cFS 组件是逐步开发并公开发布的。 核心飞行执行器 (cFE) 和平台抽象层首次用于 2009 年发射的月球勘测轨道器 (LRO)。最初的 cFS 应用套件首先用于 2014 年发射的全球降水测量 (GPM) 航天器。 整个 cFS 软件套件于 2015 年初作为开源发布(Core Flight System 2017)。
CCSDS 应用支持服务工作组目前负责开展一个名为“NASA
cFS 作为 CCSDS 机载参考架构”的项目。 这一举措突出了 cFS 的重要性。 项目代码和文档可在 NASA 的 GitHub 页面 (https://github.com/nasa/cFE) 上获得,还有一个社区页面 (http://coreflightsystem.org/) 用于获取有关 cFS 和问答的帮助 .
SAVOIR/CORDET
欧洲航天局 (ESA) 发起了一项名为 Space AVionics 开放接口架构的空间标准化计划,
SAVOIR 于 2008 年 11 月正式启动,是 ESA 年度研讨会 ADCSS(航空电子数据、控制和软件系统)(SAVOIR 2018)的成果。
SAVOIR 的目标之一是确定主要的航空电子功能并标准化它们之间的接口,以允许跨项目开发和重用构建块(Terraillon 2012)。 在 ESA 的 SAVOIR 计划的几个工作组中,有一个 SAVOIR-FAIRE 小组负责机载软件参考架构。
图3. SAVOIR-COrDeT 软件参考架构 (SAVOIR 2018)。
作为这项工作的一部分,基于应用软件和执行平台的分离(Terraillon 2012)提出了一种架构(名为面向组件的开发技术 - COrDeT)。图 3 显示了 COrDeT 参考架构的静态表示。
SAVOIR 小组的 COrDeT 输出是一个没有特定实现和 API 规则的参考架构。尽管如此,由 ESA 资助的指定 COrDeT 的财团之一的 P&P 软件公司提供了框架的正式规范和称为 C2 的 COrDeT 的 C 语言实现,可在公司网页上公开获得(P&P 软件 2018 )。
COrDeT 的 C2 实现是一个面向服务的应用程序,与 ECSS PUS 定义的服务有很强的对应关系。 ESA 的 CHEOPS 卫星有效载荷软件正在使用 C2 实施,该软件将于 2019 年飞行(P&P 软件2018)。
CCSDS 应用支持服务工作组负责开展一个名为“SAVOIR作为 CCSDS 板载参考架构”的项目,预计将于 2020 年 7 月完成。
KubOS
Kubos 是一家位于美国德克萨斯州的太空软件初创公司,成立于 2014 年。该公司开发了 KubOS 飞行软件框架,该框架具有适用于 3 个主要 CubeSat OBC 的BSP。它的完整包是开源的。用户可以为其他功能付费,例如支持服务和软件更新(kubos 2018)。
KubOS 堆栈如图 4 所示。它的层是:
Kubos Linux:专为嵌入式设备设计的定制Linux 发行版。它侧重于仅包括对空间应用有用的驱动程序(例如 I2C 和 SPI,而不是显示驱动程序)、多层系统验证和恢复逻辑。 Kubos Linux 项目内置于二进制文件中,将作为 Linux 用户空间应用程序运行
Kubos服务:Kubos 服务定义为用于与卫星交互的任何持久进程。服务很少做出决定,但允许用户完成典型的飞行软件任务,例如遥测存储、文件管理、外壳访问和硬件交互
任务应用程序:任务应用程序构成上层,几乎可以控制卫星行为。 例如,它们管理状态管理、完成脚本任务和监控板载行为。 每个应用程序通常专用于卫星应该完成的特定模式或孤立任务,以保持它们的轻量级和便携性。 它们可以很简单,例如遥测信标应用程序,也可以很复杂,例如有效载荷操作应用程序 (Kubos 2018)
图 4. KubOS 堆栈(Kubos 2018)。
KubOS 在 GitHub 存储库中开源。 首次使用的用户可以使用公司提供的 SDK 创建自己的 KubOS 项目。 值得注意的是,KubOS 是轻量级的,并为使用 Rust 或 Python 语言编写任务应用程序提供了基础。 还声称支持 C 和 Lua(Kubos 2018)。
CAST软件参考架构
中国空间技术研究院(CAST)是中国主要的航天器开发和生产机构。熊文等人。 (2015)指出,航天工程中航天器航电软件的复用问题是中国项目亟待解决的重要问题。
CAST 技术人员设计并实施了航天器航空电子软件架构。它基于 CCSDS 推荐的航天器机载接口服务 (SOIS) 和欧洲空间标准化合作组织 (ECSS) 标准推荐的数据包利用标准 (PUS)。
根据熊文等人的说法。
(2015),测试和验证的结果表明软件架构具有很好的
对软件重用的积极影响。在中国国家航天局 (CNSA) 的领导下,这项工作正在通过一个专门的工作组获得 CCSDS 标准化地位,NASA cFS 和 ESA SAVOIR 也发生了这种情况。
图 5 显示了 CAST 软件参考架构。此参考架构由以下部分组成:
操作系统层:操作系统的接口被封装,操作系统层提供统一的应用程序接口(API)。任何支持该接口的操作系统都可以在航电系统中使用
中间件:操作系统层和应用层之间的公共服务平台。具有标准的程序接口和协议,可实现不同硬件和操作系统之间的数据交换和交叉支持
应用层:包含航电系统的大部分常用功能。对于不同的项目,这一层的实现可能会有所不同。
尽管如此,CAST 源代码架构并不是开源的。没有提及任何飞行遗产。
图 5. CAST 软件参考架构(CCSDS 2016)。
纳米卫星 MO框架 (NMF)
NanoSat 任务运营服务框架 (NMF) 是一个飞行软件项目,将在 ESA 赞助的名为 OPS-SAT 的实验性纳米卫星上飞行(目标发射日期为 2019 年年中)。该任务旨在展示当卫星可以使用更强大的机载计算机飞行时将出现的任务控制能力的改进。
NMF 为基于 CCSDS MO 框架 (CCSDS 520.0-G-3) 的纳米卫星提供标准机载软件框架。它不仅有利于监测和控制纳米卫星软件应用程序,而且有利于与平台外设的交互。这是通过使用 MO 服务套件中包含的 CCSDS 任务操作监控服务和定义一组新平台服务来实现的(Coelho 等人,2016 年)。
OPS-SAT 航天器提供了一个由具有 1 GB RAM 的 MityARM 设备、一个 ARM 处理器组成的实验平台
具有 925 MHz 和轻量级 Linux 版本(Coelho 2016)。计算能力的提高是 CubeSat 项目的趋势,它允许 NMF 框架从通常的嵌入式 C 或C++ 轻量级软件转变为 Java 多平台不可知应用程序。
图 6. NanoSat MO 框架架构(Coelho 2016)。
图 6 展示了仅具有一个应用程序的 NMF 架构。 为了部署多个可以同时使用外设的应用程序,NMF 建议使用两个新组件。 其中之一是 NanoSat MO Supervisor,负责管理应用程序并提供可供不同应用程序使用的平台服务。
另一个是 NanoSat MO 连接器,负责连接到平台服务,将它们暴露给应用程序和接口的逻辑,以从地面或其他应用程序监视和控制应用程序。
科埃略等人。 (2016) 提到 NMF 和经典FSW 框架的主要区别在于 NMF 是开发的
适用于资源不稀缺但可以运行完整操作系统的系统。 NMF 框架在 GitHub 公共存储库中开源,并附带一个 SDK、OPS-SAT 卫星模拟器和用于运行该软件的技术文档。
结论
表 2 展示了框架比较研究。对上一节中提出的每个选择标准的符合性进行了单独评估。一些框架(GERICOS和 CAST)尚未开源,仅对其开发组织可用,因此难以对它们进行进一步的技术分析。
在开源框架(NASA cFS、COrDeT C2、NanoSat
MO 和 KubOS)中,每个框架提供的文档数量是不同的。例如,COrDeT 将每个软件需求单独跟踪到代码和验证证据,而 NanoSat MO 主要依赖于启发框架创建的 CCSDS 520.0-G-3 文档。
关于语义,GERICOS 和 COrDeT 是唯一创建自己的语义的,完全指定了它们的架构行为。其他人的语法分布在文档中,有时必须查看代码才能正确理解软件架构。
NASA cFS 和 GERICOS 是目前已成功执行先前任务的框架。其他人将在未来几年内获得飞行遗产。
对每个软件 SDK 的比较表明,cFS OpenSatKit 是最“交钥匙”的解决方案。它不仅提供了一个 cFS 捆绑包的运行实例,而且还提供了一个开源地面控制软件,该软件专门用于与 cFS 和一个 CubeSat 模拟器示例交互,从而提供了对框架功能的深刻见解。
CCSDS 应用支持服务工作组目前正在为三个特定框架执行一些名为“CCSDS Onboard Reference Architecture”的项目:SAVOIR、CAST 和 NASA cFS。这些证据表明,这些架构因其技术质量和可观的利用率而获得了 CCSDS 的特别认可。这种标准化工作也将有助于它们的长期存在,并将它们的概念传播到其他国际组织。
对表 2 的综合分析得出三个符合大多数选择要求的框架:SAVOIR/COrDeT、KubOS 和 cFS。
SAVOIR/COrDeT 在软件文档和语法定义方面是最完整的。但它没有飞行遗产,并且依赖于未定义的消息传递中间件来运行。因此,它不能立即使用。
顾名思义,KubOS 是专为 CubeSat 世界设计的架构。在代码占用和可移植性方面,它是一个非常合适的架构,带有交钥匙软件包。然而,除了缺乏飞行遗产外,参考任务还在寻找一个有保证的长期支持的框架。确保通过公共访问标准(CCSDS 是经认可的机构)和建立软件控制委员会委员会的一些方法。
关于软件质量和长期技术支持,cFS 由专门的 NASA 配置控制委员会管理,该委员会控制和批准未来对 cFS 核心和主要应用程序的更改。软件核心的维护和演进则由 NASA 完成,NASA 也是 cFS 框架的主要用户。对于想要依赖第三方框架的太空组织来说,长期支持标准是关键。
根据框架比较(表 2)中提供的结果和上一节中定义的标准,NASA cFS 是最符合纳米卫星参考任务需求和约束的框架。因此,它被 VCUB1 任务采用作为设计基准。
表 2.
FSW 框架对比表。
Criteria | cFS | COrDeT/SAVOIR (through
C2) | CAST | GERICOS | KubOS | NanoSat
MO | |
1.1 | Open-source | Yes (GitHub) | Yes (C2 implementation, in GitHub) | No | No | Yes (GitHub) | Yes (GitHub) |
1.2 | Technical documentation | Yes | Yes | No | No | Yes | Yes |
1.3 | Demo/training | Yes (OpenSatKit) | Yes(there is a demo in C2) | No | No | Yes (KubOS SDK) | Yes (NMF SDK) |
2 | Flight heritage | Yes | No(ESA’s
CHEOPS
to
be launched in 2019) | No | Yes(PicSat launched in Jan 2018) | No (TBC) | No(ESA’s
Ops-Sat
to
be launched in 2019) |
3 | Small footprint | Yes | Yes | Yes | Yes | Yes | No(Java implementation requires a powerful OBC) |
4.1 | Reliability | Yes, | Yes | Not found | Not found | Yes | Not found |
4.2 | Formal specification | 部分合规(没有集中的 cFS 架构规则文档。规则通过文档传播) | 是(CORDET 框架 C2 实现 - 用户要求) | 部分符合(框架声称完全符合 CCSDS SOIS 和 ECSS PUS) | 部分符合(框架声称符合某些 ECSS PUS 服务) | 部分兼容(没有 KubOS 架构规则证明。规则可通过 API 的文档找到) | 部分符合(没有集中的 NMF 架构规则文档。但是,框架声称完全符合 CCSDS 520.0-G-3) |
4.3 | Well-defined semantics | 部分兼容(没有语义模型或文档。有一个 cFS 示例应用程序,其中包含基本 API 调用和开发人员用户指南) | Yes (CORDET C1 framework profile) | Not found | Yes (GERICOS UML Profile) | 部分兼容(没有语义模型或文档。有一些模板任务应用程序包含基本的 KubOS API 调用) | 部分兼容的模型或文档。 开发指南) |
4.4 | Requirements traceability | 部分合规(存在 cFE 和 cFS 套件要求,但未追溯到代码) | Yes(记录在 CORDET 框架 C2 实现中 - 用户要求) | Not found | Not found | Not found | 部分兼容(存在非常短的 NMF 软件要求列表,但未追溯到代码) |
4.5 | Modularity (component-based design) | Yes | Yes | Not found | Yes | Yes | Yes |
4.6 | Portability(to several RTOS and processor cards) | Yes(cFS OSAL 允许这样做) | N/A(C2 实现在未定义的消息传递中间件之上) | Yes(根据 CSDS CAST 架构文档是这么说的) | Yes(GERICOS::CORE 允许这样做) | Yes (GERICOS::CORE 允许这样做) | Yes(可移植到 FreeRTOS、Linux 和某些 CubeSat OBC) |
5 | Long-term support | Yes (NASA support) | Yes (ESA support) | Yes (CAST support) | Yes (LESIA support) | Yes (KubOS company support) | Not
found
(no
explicit mention in ESA’s documentation) |
6 | User-community collaboration | Yes (through GitHub tickets) | Yes (because CORDET GitHub) | No | No | Yes (through GitHub tickets) | Yes |
7 | CCSDS standardization | Yes | Yes | Yes | No | No | 部分(未被特定工作组标准化为参考体系结构,但它是CCSDS 520.0-G-3标准的衍生产品) |
结论和今后的工作
根据纳米卫星参考任务选择标准,分析了六个相关的FSW框架。由于成本低、进度短、管理和可靠性理念以及使用COTS部件的特点,作者的立方体卫星任务可以被视为一个典型的新航天项目。经过仔细的合规性分析后采用的解决方案是NASA cFS。
在文献研究中,作者发现了许多由学术界精心设计的软件体系结构。这些解决方案通常是围绕各自大学的单个纳米或小型卫星项目开发的。这些架构,例如Switerzland EPFL的BIP框架(Mavridou et al.2016)和美国佛蒙特州CubedOS技术学院(佛蒙特技术学院2017),尽管很有趣,但由于决定强调在多个项目中具有潜在可重用性的框架,因此没有对其进行分析。不过,这些解决方案可以在未来的工作中探索。
商业解决方案,如Terma的Oboss(Terma
2004)和Scisys的飞行软件(Scisys 2018),尽管经过飞行验证,但无法用于进一步分析。
值得承认的是,有两个框架被推荐给作者,但考虑太晚了,无法在本文中考虑:RODOS和F Prime。德国的“实时面向对象分布式操作系统”(RODOS)(Dannemann and Montegon 2013)包含一个面向对象的中间件,这是一个有趣的空间应用开源框架。NASA JPL“F Prime”框架最近发布。它说明了与cFS相比的一些差异。例如,F Prime架构使用带有类型化连接的静态拓扑,而cFS使用软件总线上的发布-订阅(Bocchino
Jr.et al.2018)。RODOS和F Prime将在未来的工作中进行探索。
参考文献
1. BocchinoJr. RL, CanhamTK, Watney GJ, Reder LJ, Levison JW (2018) F Prime: an open-source framework for small-scale flightsoftware systems.Presented at: 32ndAnnual AIAA/USU Conference on Small Satellites; Logan, USA.
2. CCSDS (2016) CAST flight softwareas a CCSDS OnBoard referencearchitecture. Washington: CCSDS.
3. Chin A, CoelhoR, Brooks L, Nugent R, Puig-Suari J (2008) Standardization promotes flexibility: a review of CubeSats’ success.Presented at: 6th Responsive Space Conference; Los Angeles USA.
4. Coelho C, KoudelkaO, Merri M (2016). NanoSatMO framework: achieving on-board software portability. Presented at: SpaceOps 2016 Conference; Daejeon, Korea. https://doi.org/10.2514/6.2016-2624
5. Conto A, Mattei AP, Saquis-Sannes P, Carvalho H, Miranda D, Balbino F (2018) Use of SysML and model-based system engineering in the development of the Braziliansatellite VCUB1. Presentedat: 10th European Cubesat Symposium; Toulouse,France.
6. Core Flight System(2017) About the technology and why cFS. Core FlightSystem; [accessed 2018 May 18]. http://coreflightsystem. org/why-cfs/
7. DannemannF, Montenegro S (2013) Embeddedlogging framework for spacecrafts. Presented at: DASIA 2013 DAta SystemsIn Aerospace; Porto, Portugal.
8. Dvorak DL (2009)NASA study on flight softwarecomplexity. Presented at: AIAA Infotech@Aerospace Conference; Seatle, USA. https:// doi.org/10.2514/6.2009-1882
9. EickhoffJ (2012) Onboard computers, onboardsoftware and satelliteoperations: an introduction. Berlin: Springer. Kubos (2018) KubOS;[accessed 2018 July 10]. https://docs.kubos.com/1.5.0/index.html
10. KucinskisNF, Ferreira VGM (2013)On-board satellite software architecture for the goal-based Brazilian mission operations. IEEEAerospace and Electronic Systems Magazine 28(8):32-45. https://doi.org/10.1109/MAES.2013.6575409
11. Lapeyrere V, Lacour S, David L, Nowak M, Crouzier A, SchworerG, Perrot P, Rayane S (2017) PicSat: a Cubesat mission for exoplanetary transit detection in 2017. Presentedat: 31st AnnualAIAA/USU Conference on Small Satellites; Logan, USA.
12. Mavridou A, Stachtiari E, Bliudze S, Ivanov A, Katsaros P, Sifakis J (2016) Architecture-based design: a satellite on-board software case study. In: Kouchnarenko O, Khosravi R, editors. FormalAspects of Component Software. FACS 2016. Cham:Springer. https://doi. org/10.1007/978-3-319-57666-4_16
13. NASA (2014) core Flight System (cFS) Backgroundand Overview. NASA; [accessed 2017 February 5]. https://cfs.gsfc.nasa.gov/cFS- OviewBGSlideDeck-ExportControl-Final.pdf
14. NASA (2017) NASA software catalog2017-2018. NASA; [accessed 2017 November 25].https://software.nasa.gov/ NASA_Software_ Catalog_2017-18.pdf
15. Paikowsky, D (2017) What is new space? The changing ecosystemof global space activity. New Space 5(2):84-88. https://doi. org/10.1089/space.2016.0027
16. Plasson P, Cuomo C, GabrielG, Gauthier N; Gueguen L, Malac-Allain L (2016) GERICOS:A Generic Frameworkfor the development of on-board software. Presented at: DASIA 2016. Data Systemsin Aerospace; Tallin, Estonia.
17. P&P Software (2018) CORDET C2 Implementation Download.P&P Software; [accessed2018 May 1]. https://www.pnp-software.com/ cordetfw/download.html
18. Rexroat JT (2014)Proposed Middleware Solutionfor Resource-Constrained Distributed Embedded Networks (Master’s Dissertation). Lexington: University of Kentucky.
19. SAVOIR (2018) SAVOIR Outputs. SAVOIR; [accessed 2018 May 1]. http://savoir.estec.esa.int/SAVOIROutput.htm
20. Schmidt DC, Gokhale A, NatarajanB (2004) Leveraging application frameworks: why frameworks are important and how to apply them effectively. ACM Queue 2(5):66. https://doi.org/10.1145/1016998.1017005
21. Scisys (2018) SCISYSflight software brochure. Scisys; [accessed 2018 May 1]. https://www.scisys.co.uk/fileadmin/user_upload/ Downloads/Operational_Divisions/Space/SCISYS-Space-Flight-Software-2018.pdf
22. Swartwout M (2013) The first one hundredCubeSats: a statistical look. Journal of Small Satellites 2(2):213-233.
23. Terma (2004) Onboard Operations Support Software homepage. Terma; [accessed 2018 May 1]. http://spd-web.terma.com/Projects/ OBOSS/Home_Page/
24. Terraillon JL (2012) SAVOIR: Reusing specifications to improve the way we deliver avionics.Presented at: EmbeddedReal Time Software and Systems;Toulouse, France.
25. Vermont Technical College (2017) CubedOS projectoverview. VermontTechnical CollegeCubeSat Laboratory; [accessed 2018 May 1].
26. http://cubesatlab.org/CubedOS.jsp
27. Wilmot J, Fesq L, Dvorak D (2016) Quality attributes for mission flight software: a reference for architects. Presentedat: IEEE Aerospace Conference; Big Sky, USA. https://doi.org/10.1109/AERO.2016.7500850
28. Xiongwen H, Bowen C, Dong Y, Jianbing Z, Ming G (2015) Design and implementation of spacecraft avionics software architecture based on spacecraft onboardinterface services and packet utilization standard. Presented at: International Astronautical Congress; Jerusalem, Israel.
特别说明:文章题材来自于网络,若涉及版权问题,请联系删除!