系列研究 | NASA 软件架构建议(二)
点击
“航天软件和数字化”
关注我们
本公众号将定期更新对 NASA 的飞行软件的近年工作全面调研和分析的汇编,本系列仅做学术交流使用。
上文讲了关于飞行软件架构的4点建议,这是NASA几大研究中心针对软件复杂度问题,共同提出的解决方案,也成为2009年之后NASA很多软件投资和活动的基础。本文将关注4个建议的落实情况。
可以通过NASA软件工程手册SWEHB (https://swehb.nasa.gov)得到验证,软件架构已经是 NASA 软件工程需求标准规定的软件生命周期的基本组成部分,处于软件需求分析和软件设计之间,需要形成详细的架构描述。下表是NASA软件工程手册中关于软件工程生命周期中,软件架构需求的描述:
软件架构 | SWE-057 - Software Architecture |
在需求完成之后,需要进行软件的架构设计,并通过文档明确描述,内容包括: ● 不同架构选择的依据 ● 所选择架构的描述 ● 子系统的构成 ● 子系统的依赖 ● 架构完整性的评估方法 ● 所选架构的风险 ● 架构变更的依据 ● 架构变更的影响 |
SWE-143 - Software Architecture Review | 对于1类软件和2类软件的A级和B级,都需要由软件架构评审委员会(SARB)进行软件架构评审 |
NASA的软件架构评审委员会是根据2009年的《NASA飞行软件复杂度研究报告》建立起来的,其主要使命是“通过更好的架构管理软件复杂性”。任何 NASA 的项目都可以申请“架构评审”。
涉及NASA内部的软件架构人才支持项目,并没有搜到直接相关的内容,但是从2009年的建议以及后续实践中,我们可以推断出,在相关的基金和计划中,软件架构人才的培养, 必然已经成为NASA高度优先的任务之一。
建议4中点名提到了两个可能的候选参考架构,即GSFC的核心飞行系统 (Core Flight System, CFS)和JPL的任务系统架构平台(Mission System Architecture Platform)。在后续的发展中,JPL的飞行软件架构始终是内部使用,称之为“飞行软件软件产品线”。GSFC的CFS系统,则选择了开源路线,在经过起初几年的广泛讨论后,尤其是2012年架构评审委员会对CFS的架构评审后,CFS逐渐成为事实上的参考架构,迅速推广应用到GSFC,JSC,ARC和APL等中心数十个任务中。2014年起,CFS正式对NASA以外开源并成立社区,吸引了大量国际用户和爱好者,包括韩国,巴西,阿根廷,日本等。也是从2014年起,CFS的开发者和用户进行每年一次的CFS会议,为期一天,就CFS的开发状况,后续方向,以及实践经验等进行交流。会议的文档材料和视频都公开分享,更加推动了CFS的广泛传播。
2007年到2009年,NASA总工程师办公室组织几大研究中心和实验室对飞行软件复杂度问题进行了深入研究,最终发布了《NASA飞行软件复杂度研究报告》。这个报告对NASA飞行软件的研发提出了一系列改进建议,对后续飞行软件的研发产生了巨大影响。在软件架构方面,对研发流程,工程管理,技术工具,人才培养等都作出了方向性指南。作为报告的核心建议内容之一,NASA范围内通用飞行软件参考架构也已经逐渐明朗。JPL的软件产品线虽然独具特色,也已经通过诸多深空任务,尤其是火星探测器的实践检验,但是也仅在JPL内部使用。GSFC的核心飞行系统CFS则采取了开源的方式,首先是在NASA内部,2014年后更是完全开源,通过软件社区,联合诸多研究中心共同推进研发,这也大大促进了其推广应用,包括 GSFC,JSC,ARC和APL等中心数十个任务。从2011年起,在每年的NASA飞行软件年会中,都有CFS的相关报告。从2015年起,CFS更是成立了独立的年度研讨会。由于这些报告文档和视频都可以在线获得,结合CFS的开源代码,构成了本报告的内容基础。
点击阅读原文,了解更多