【“猫”眼看天丨专栏】从那行毁了18亿日本卫星的代码看软件风险

底层软件BUG葬送了日本18亿的天文卫星，软件风险，不可小觑！...

编者按：

4月底，JAXA无奈宣布其X射线卫星“瞳”已经彻底毁掉，令人大跌眼镜的是事故原因居然是一行写反的代码（消旋的喷气指令极性搞反了）。原本是用于关键时刻救命的代码，却未经完整测试就发送了上去，结果...你懂的......项目负责人表示，我们成功用“瞳”观测了3天，可是本来我们打算用它10年的......底层软件BUG葬送了日本这台价值18亿的天文卫星。软件风险，不可小觑啊。今天，“猫”眼看天专栏，大咖带大家一起了解航天项目中的软件风险。

日本“瞳”X射线天文望远镜的故障，又一次勾起了人们对航天项目中软件风险的担心。对不熟悉软件技术的管理者而言，航天嵌入式软件（即没有用户界面和人机交互的软件）看不见、摸不着，始终是块心病；而对程序员而言，这些软件就是自己一手打造的杰作，再熟悉不过了，让他们承认还有瑕疵，心里总是有点不以为然。这种认识上的差异，导致管理者制定的软件保证措施往往针对性不强而效果不佳，而设计方出于自信对质量保证活动不够积极而流于形式。那么，究竟怎样做才能消除软件风险呢？

软件的失效（错误）

错误和失效在可靠性术语中是两个含义，例如，错误并不一定导致失效，但为了易于理解，在本文中没有刻意区分二者的含义。软件在航天活动中扮演着重要的角色，据NASA统计，从1998年至2007年这十年间，在高风险的航天项目中，由软件造成的故障占到了故障总数的60%（NASA PRA Procedures Guide, 2010）。软件故障的定义是：“飞行计算机软件执行了错误的动作，或者未能执行预定的动作，或者在错误的时间执行了相应的动作。”（NASA ShuttleProbabilistic Risk Assessment (PRA), SSA-08-11 rev B）

下面列举几个典型软件失效案例：

1962 - Mariner 1 (公式编码不正确)
1988 - Phobos (使推进器不工作)
1996 - Ariane 5 (重用了Ariane4的软件)
1999 - Mars Polar Lander (降落时未能正确处理湍流)
1999 - Mars Climate Orbiter (单位转换错误)
2004 - Spirit (flash内存满)
2005 - CryoSat-1 (遗漏关机指令)
2006 - Mars Global Surveyor (误判电机故障)
2011 - Express-AM4 (参数错误)

针对各种软件错误，专家们归纳出出错的三大类原因，分别是编码错误、上下文隐藏的错误和操作系统错误。

编码错误自然是由于设计或编码错误而导致的，如果在首次飞行前的测试中没有被发现，就有可能导致飞行失败；这种错误的特征是在正常的任务条件下就有可能发作。

上下文隐藏的错误主要是由于对需求的理解不够全面、或者需求描述不够透彻等等因为理解上的误解而造成的错误。程序员们常常抱怨，“我的代码能够满足相应需求，但在非额定条件和无法预料的情况下除外！”问题是，哪些是非额定条件和无法预料的条件？遇到这类条件应该如何处理？这些问题可能从一开始就没有交代清楚，也由此埋下了隐患。因此，这类错误常在非额定状态下发作，并且可能需要非常特别的条件才会激发，也难以在一般的测试中被发现。但现实情况是，系统不可能工作在额定的理想情况下，软件应该能适应一定偏差的状况。

操作系统的错误是由于使用嵌入式操作系统而带来的，它实质上是将飞行软件出错的可能性转嫁到了自己身上，典型的错误模式如：对应用程序的响应出错、内存分配错误、后台处理出错等。

软件分析风险

对于一项重大的航天活动，风险分析是质量保证活动的一项重要内容，以美国SLS重型运载火箭为例，如何有效地分析软件风险，也一直在考验着他们的工程技术人员。

专家们提出了如下几种分析风险的方法：

采用基于SLS飞行数据的数学模型。可以看出，NASA非常重视模型的作用，风险分析这么重要的工作自然也要建立起数学模型而不能仅仅做些定性分析。他们认为采用实际飞行数据是真实可信的（假设有大量的用于分析的数据集），但唯一缺点是首飞前没有数据可用，这也是经常看到NASA开展试验性飞行验证以及应用DFI的原因——在真正投入使用前要进行试飞，这样的试飞算不上“首飞”。
基于相似系统历史数据的数学模型。如果经费紧张无法安排试飞，可以采取这种方法。其分析的可信度具有较低/中等的不确定性，这些数据需要针对SLS实际情况进行适应性修正，并且必须能够有效地合并到SLS的软件测试数据或飞行数据中。
采用一般统计数据的启发式方法。这种方法基于某种风险模型，其分析结果具有中度的不确定性。不同的方法有不同的结果。当然，有些机构喜欢让专家来评判风险，NASA自然也不忘提出建议：这类方法具有高度的不确定性！（言下之意，让专家来判断风险的风险很大！）

风险模型示例

工程师们开发出了多种风险模型，没有哪种模型最好，要针对软件特点找到最适合的模型。例如采用基于上下文的软件风险模型(CSRM)，在这种模型中考虑非额定状态下的场景（额定状态下的场景早在各种测试中已经充分验证了）以及特定的软件失效模式。又如Ann Marie Neufelder倡议的SOFTREL方法（可在网上找到相应介绍）。下文图1介绍了一种基于各种复杂度评估的分析模型。

图1 风险模型示例

软件越复杂，编程者越容易犯错，测试也变得困难，因此风险指数也高，这是个朴素的概念。因此，有学者提出了如图1所示的软件风险模型，分为两大组成部分:可能性及后果。其中可能性从评价软件质量的量化指标和测试覆盖率角度（未测试覆盖的代码大约占到多少百分比）进行分析。在后果分析方面，主要考虑功能性的严重程度，通过对需求、设计输入和用户输入，进行安全性分析和风险评估，最后得出严酷度的等级。

通过量化指标对软件的复杂性进行定量评估，包括可测试性，代码的复杂度，接口的危害性，可维护性等四个方面，每个方面又细分为多项评价因素，如图2所示：

图2 复杂度分析蛛网图

例如，在可测试性方面，需要考虑模块化设计的复杂度，圈复杂度，病态数据复杂度等。最后综合出一个敏感性指标，并结合后果分析结果，最终得出风险指数。

对于采用瀑布式模型来开发的软件，风险分析也存在一个瀑布式的过程，如图3所示。

图3 全生命周期的风险分析过程

如果等所有软件开发过程全部结束再分析风险，若发现风险较大的环节，此时消除风险的代价就太大了，因此，风险分析与软件设计和评测要同策划，同部署，同开展。在需求分析阶段，要进行安全性评估，分析功能的严酷度。在设计和编码阶段，要进行各项指标的量化分析，对编码的复杂度进行测试。在子系统测试阶段，要对测试覆盖性进行统计并给出测试用例的建议。在集成测试阶段，除测试覆盖率分析外，要对软件的可靠性进行预计。在用户接收阶段，要给出风险指数和可靠性指标。

LESSON LEARNED

最后，本文给出一些控制软件风险的经验教训，当然这并不是全面地从整个软件生命周期的开发来总结的，而是重点针对可能会被忽略的环节或需要重点强调的环节：

软件专家应该从早期的任务制定阶段就介入到项目中，而不应该在接到任务书后才开展工作。某一项功能由地面系统还是飞行系统来实现，由软件还是硬件来实现，以及任务费用的估计等，均需要软件专家参与。
软件开发与测试流程要合理安排资源，以获取最大回报。测试不是开发的附属品，其投入的资源可能比开发还要多，这个观念一定要牢记心中。
详细的软件需求异常重要。“充分的交流”将起到重要作用，并且要在开发者、测试者、系统工程师、地面操作人员、硬件系统工程师之间形成一致且清晰的理解，避免出现上文提到的“上下文隐藏的错误。”
接口控制文档（ICD）要作为重要的设计依据。软硬件之间的接口定义要详细地描述并文档化，各方审核会签。
对软件需求、设计、编码、测试用例、测试结果的正式和非正式审查同等重要。在审查过程中，软件专家、系统工程师、硬件分析人员、操作者均要参与，例如避免在需求中包含设计信息，通过走查发现错误，通过正式审查（包括现场演示）提升项目风险分析的粒度（分辨率），等等。
高可信度的软件测试平台是必须的配备，这一点不容商量！唯一确认软件能否正常工作的方法是在类似飞行的环境中进行测试。如果没有这样的环境，就像一个机械工程师在半负载条件下测试他们的硬件，或者电气工程师在欠压下测试他们的电路。这样的测试平台应该能够模拟额定和非额定等各种工况，必须涵盖在地面条件下软件验证的各种要求，也有助于软件的维护。
发现错误的最佳时期是在其刚刚引入时。那种将所有工作都留到最后的思路是不正确的，若到项目的最后阶段才安排第三方确认测试，一旦发现问题，修改软件设计带来的代价比及早发现问题要高很多，比如，已经开展的试验是否要全部重做？因此，测试工作应在软件版本基本确定后就及早开展。

风险分析工作的难度很大，对软件尤其如此。只有找到有效的方法，才能真正起到作用；一旦真正起到作用，才会引起设计人员的重视和认同，从而在质量保证人员和设计人员之间形成良性互动。而无效的方法，浪费了精力和资源，严重的情况下给设计人员带来了逆反和疲劳的反应，即使风险分析报告写得再完美，也没有任何实际效果。

编后语：

近年来，日本通过积极参与国际航天合作，自身水平提高得也很快。例如，全球首个采用太阳帆推进的航天器（(IKAROS）就由日本试验成功。日本还积极参与NASA、ESA关于质量保证工作经验的交流，形成了三家航天政府机构每两年一次的常态化交流机制，下一届将于明年在日本举行，俨然有“三强鼎立”之意。美、加等国对日本也信任有加，在“瞳”天文望远镜上还搭载了自家的设备。只是不知明年的TRISMAC（Trilateral safety and mission assurance conference）会议上，JAXA将怎样总结他们的经验教训呢？各项发射任务在即，我们自身更要引以为戒啊。

（注：原创作品，转载请与我们联系！）

微言航天，分享我们对航天的认知和观点。
欢迎投稿，微言大义，共绘航天。
邮箱：vc_space@qq.com
小管家微信号：space-rose