系列研究 | NASA 软件架构建议（一）

2007 年，面对不断加剧的飞行软件“复杂度危机”，NASA 总工程师办公室 (OCE)组织各研究中心的工程师和管理人员，针对主要任务中飞行软件遇到的问 题进行综合分析，最终于 2009 年发布了《NASA 飞行软件复杂度研究报告》（以 下简称“复杂度报告”）。

这是 NASA 飞行软件领域一个承前启后的纲领性文件， 它一方面详细分析了过去几十年 NASA 各种任务（载人和非载人）飞行软件规 模和复杂度的增长，总结复杂软件开发实践中有效的设计与测试经验；另一方面 提出 15 项降低和管理飞行软件复杂度的建议措施，为 NASA 未来飞行软件的发 展指明了方向。根据“复杂度报告”确定的纲领，近十几年 NASA 各机构在复杂飞行软件的开发、验证和标准方面开展了大量开创性的工作，取得显著进展，新的技术和方法逐步推广应用。

这些措施总结起来可以概括为：“以软件系统化为中心，开发和推广飞行软件参考架构，组织建立架构评审 委员会，培养和引进软件架构人才，编制软件工程手册推动流程、管理、保证与工具的统一化、制度化和标准化，积极采用新的软件开发技术与工具，进而推动 电子系统的升级，通过软硬件协同设计，有效解决飞行软件的复杂度危机”。

随着载人航天，探月，行星探测等工程任务的实施，中国航天飞行软件的复 杂度也在急速攀升，风险与挑战也在不断增加。我们希望通过收集 NASA 近十 几年在解决飞行软件复杂度危机方面的所采取的措施和方法，为中国航天飞行软件的未来发展提供借鉴。

第一章 NASA 飞行软件架构研究

软件架构是《NASA 飞行软件复杂度研究报告》重点阐述的内容之一，被认为是解决软件复杂度问题的主要手段。在 15 项解决软件复杂度问题的建议中，有 4 项是关于软件架构的：

(1) 加强早期分析和架构设计；

(2) 实施架构评审；

(3) 培养软件架构师；

(4) 构建参考架构；

在《NASA 飞行软件复杂度研究报告》附录 H 中，来自 JPL 的 Robert. D.Rasmussen 对飞行软件的复杂度现状，以及架构设计在解决复杂度问题中所起的作用进行了深入分析，并基于认知模型，提出了基于状态的架构、基于目标的架构和基于模型的架构，为飞行软件架构设计提供了思想指导。

本文针对《NASA 飞行软件复杂度研究报告》的 4 项建议以及架构设计思考，调研并总结 NASA 在软件架构方面开展的工作，希望对国内航天系统与软件设计开发人员有所帮助。

系列一NASA 飞行软件复杂度研究

2009 年，NASA 总工程师办公室(OCE)经过两年的组织研究，发布了《NASA 飞行软件复杂度研究报告》，对过去 40 年的大量任务（包括已发射和未发射的） 飞行软件问题进行了综合分析，主要内容包括：分析飞行软件规模和复杂度的增 长，提供降低和管理复杂度的建议，甄别复杂逻辑测试的方法，研究因软件复杂 度增长导致的故障保护机制等。

参与研究的人员包括 NASA 各中心和实验室的 工程和管理人员，主要是应用物理实验室（APL），Goddard 空间飞行中心（GSFC）， 喷气推进实验室（JPL），Johnson 空间中心（JSC），Marshall 空间飞行中心（MSFC）。根据《NASA 飞行软件复杂度研究报告》的统计和预测，NASA 各中心飞行软件的规模和复杂度迅速膨胀，速度大约是每 10 年提升一个数量级。而解决软件复杂度问题没有“银弹”，只能依靠“最佳实践”，其中软件架构将是缓解复杂度的关键技术手段。针对飞行软件架构，报告提出了4项建议。

1.加强早期分析和架构设计

在工程项目中，越早发现的问题和错误损失就越小，对于软件复杂度问题也一样。一旦需求确定，接下来就是软件架构设计，包括功能需求和非功能需求。就像每一栋建筑一样，每一款软件都有其架构。一种软件架构就可能比另一种更加适合， 如同一栋建筑就比其他的要好一样，这说明除了满足功能需求，好的软件架构需要满足一系列质量特性，例如复杂性，可维护性，可测性，可扩展性和可交互性等。

NASA 报告指出，目前软件架构差的两个主要现实情况：其一，软件架构作为软件工程课程是比较近期出现的。例如，最早讨论这个话题的书出现在 1996 年。在目前飞行器项目中，有一定职位的几乎没人经过软件架构教育。其二，软件架构随着软件系统规模的不断增加才开始受到重视，好的架构能够使得项目成功，而差的架构则使项目集成、试验等后续过程中无休止地出现问题。著名计算机科学家 Alan Kay 说过“观点占 IQ 80 分”，而架构恰恰代表着软件的“观点”， 对成败具有重要作用。

如果将一个项目看做是“零和”游戏，因为工程不同阶段分配的资金就是固定的，如何才能保证项目的成功呢？答案是大部分项目都大比例的投入放置到早 期的分析和架构设计阶段，避免后期的问题和返工。COCOMO II 花费评估模型对工业界软件工程影响甚远，其结论也是增加架构设计的投入比例。

如图所示，针对系统的规模，存在一个架构“最优点”。例如对于拥有 100000 行代码的一个系统，将 21%的预算投向架构设计能够最优化整体费用。类似的， 越大的系统需要更多的架构预算才能降低整体开销。此外，预算不足造成的危害要大于预算过度，因为脆弱的架构在开发、集成和测试时通常需要更多的返工。

2.实施架构评审

电信行业对软件密集型系统具有长期的开发经验，尤其是 1960 年代使用计算机控制的交换系统以后，AT&T发现大型复杂的软件项目经常严重滞后而影响上市，上市后由于质量问题以及不满足预定的功能需求而名声狼藉。为了解决问题，从1988年开始AT&T启动了“架构评审”制度，从1989 到 2000年共举办700多场，结果发现非常高效，平均每个100000行无注释代码的项目节省100000美元，因此后来即使在非常困难的财政紧缩时代也没有间断这项制度。

AT&T 指出架构评审的重要价值，主要基于：

● 在开发中早期发现问题，从而弥补花费更少。

● 能够利用公司中具有丰富经验的专家。

● 能够使得公司更好的管理软件组件供应商。

● 通过更直观的方式提高技术和项目管理能力。

● 通过评审团队对一致性和完整性的批评，形成更好的问题描述。● 在经常犯错的领域迅速识别问题并展开培训(例如，当很多评审指出性能问题 时在公司范围内开设性能课程)。

● 增强产品间交流和学习。

● 通过评审团队在不同项目的实践，提高成熟经验在公司内的传播。 

AT&T的领先实践引起了美国国防部的重视 ， 最佳践案网站 (http://bpch.dau.mil)将其列为最佳实践之一。卡耐基梅隆大学的软件工程研究所 称“正规的软件架构评审应当作为以架构为基础的软件生命周期的标准组成部分”，并出版了相关书籍介绍三种评估软件架构的方法。

NASA报告建议建立一个“架构评审委员会”，无论是在研究中心内部或 是整个NASA，起初可针对自愿的项目。IEEE Software 上的文章对概念、参与 者、过程、成果、经验和组织等进行了极好的描述。评审能够增强项目之间的交 流，帮助组织的改进。因此，NASA 应当对 AT&T 评审方式进行调整以适合飞行器工程，充分使用现有的软件架构评审研究成果，例如“软件架构评审过程”和 “同行专家评审单”。

尽管每一个 NASA 任务都是独一无二的，但是所有的飞行系统都提供一系列共有的功能：制导、轨道控制、温度控制、上行链路、下行链路、指令、遥测、 数据管理、故障保护等。虽然任务之间的细节各不相同，但是这些共性功能的存在以及之间的相互依赖，导致大部分工程都不是从零开始，而是都从之前的任务中吸收软件以降低开销。但是真实情况下，开销的降低通常比预期要少，因为复用的软件经常不是完全匹配，软件开发团队需要检查和分析每一行代码。

改变这种软件重用情况的方法是参考架构和核心功能，最大化适应性。IBM Rational 将参考架构作为“最佳实践中的最佳”，并将参考架构作为“预定义的 架构模板，或模板集，已经部分或全部经过实现、设计或证明，在特定商业或技 术领域是成功应用的”。更重要的是，参考设计包含着经验、最佳实践、架构原理和设计模式，因此可以使得诸多好思想能够得到应用，而不仅仅停留在纸面上。经验只有通过应用才是真正的经验，而参考架构提供了一种手段。 

Earmark基金，不同于任务资金，主要用于各中心参考架构的开发和维护， 该投资应当包含参考架构的软件组件，为改造或扩展提供基础。NASA/GSFC 已 经在这个领域迈出了步伐，开发了一套可重用的飞行软件系统“核心飞行软件系 统(Core Flight Software System)”。该架构强调消息传递中间件和即插即用组件， 并且已经在新的任务应用中有效降低开发成本。类似的，NASA/JPL 也在开发一套“任务系统架构平台(Mission System Architecture Platform)”。因为参考架构将用于多个任务，因此必须应该经过仔细的评审。