本节书摘来自异步社区《软件工程（第4版?修订版）》一书中的第1章1.10节实时系统的例子，作者【美】Shari Lawrence Pfleeger , 【加】Joanne M.Atlee，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.10 实时系统的例子
软件工程（第4版•修订版）
下面举个实时系统的例子，我们来看阿丽亚娜5型火箭中的嵌入式软件。阿丽亚娜5型火箭属于欧洲航天局（ESA）。1996年6月4日，在它的首次航行中，发射大约飞行了40秒钟后开始偏离航向，在地面控制系统的引导下，火箭通过远程控制被销毁。销毁这个未保过险的火箭不仅损失了火箭本身，而且也损失了它装载的4颗卫星。这次灾难共造成5亿美元的损失（Newsbytes home page 1996；Lions et al. 1996）。

从火箭导航系统到它各个组成部分的运行，几乎所有方面都与软件有关。火箭发射的失败以及随后的销毁提出了很多与软件质量有关的问题。在后面的章节中会看到，调查委员会在调查原因时，把重点放在了软件质量及软件质量保证上。在本章，我们根据火箭的商业价值来探讨质量问题。

许多组织机构在阿丽亚娜5型火箭中有投资，包括ESA、法国*国家航天局（CNES，负责阿丽亚娜计划的全面指挥），以及其他12个欧洲国家。不断的延期和一连串问题损害了阿丽亚娜火箭计划，这些问题还包括在1995年测试引擎的过程中，由于氮气泄漏导致两位工程师死亡的事故。但是，1996年6月的事故是首次直接由软件失效导致的。

这次事故的商业影响远远超过了5亿美元的设备损失。1996年，阿丽亚娜4型及其以前型号获得了全球一半以上的发射合同，领先于美国、俄罗斯以及中国的运载火箭。因此，这次事故不仅使计划的可信度大受损害，也使阿丽亚娜火箭的商业前景充满危机。

新的生意部分基于新火箭能够把更重的负荷运载到轨道。阿丽亚娜5的设计目标是能运载一颗重达6.8吨的卫星或两颗合在一起重达5.9吨的卫星，进一步的目标是希望在2002年之前达到更大的运载能力。这些增加的运载能力具有明显的商业优势。通常，操作人员通过多颗卫星共用一个火箭来减少发射费用，因此，阿丽亚娜能够同时运载多家公司的卫星。

在这个例子的背景下，我们考虑一下质量的含义是什么。阿丽亚娜5型火箭的销毁证实，这个灾难性后果的原因是客户错误地说明了需求。既然这样，开发人员可能声称系统仍然是高质量的，只不过是根据错误的需求规格说明构造了系统。的确，调查委员会在总结事故原因和补救措施时指出：

委员会的调查结果是基于阿丽亚娜5项目组完全的公开介绍和文档，这些文档从总体上表明，从工程技术以及文档的完整性和文档可跟踪性来说，阿丽亚娜5的程序是高质量的（Lions et al. 1996）。

但是从用户和客户的观点来看，规格说明的过程已经足够好，能够确定规格说明中的缺陷，并且在灾难发生前，使客户能够改正规格说明中的缺陷。调查委员会认识到：

SRI（最终找到的引起问题的子系统）的厂商仅仅是遵循了给定的规格说明，即在检测到任何异常的情况下，处理器将终止执行。异常的发生并不是因为偶尔的失效，而是由于一个设计错误。异常被检测到了，但是并没有被适当处理。原因是采用了这样一种观点，即在软件发生故障之前，就应该认为它是正确的。委员会有理由相信阿丽亚娜5软件设计的其他部分也采纳了这个观点，而委员会支持相反的观点：应该假定软件是有故障的，直到应用了目前可接受的最好的实践方法并能够证明它是正确的（Lions et al. 1996）。

在后面的章节中，我们将更详细地研究这个例子，探讨开发人员和客户决策中的设计、测试和维护的含义。我们将看到，在开发初期，低质量的系统工程是如何导致一系列决策失误，进而又是如何导致一系列灾难发生的。另一方面，包括ESA和调查委员会等所有相关机构的开诚布公，以及高质量的文档和尽快得知真相的最真诚的愿望，促成了眼前问题的快速解决和防止未来类似问题发生的有效计划。

系统的观点使调查委员会和开发人员可以把阿丽亚娜5看作子系统的集合。这个集合反映了对问题的分析，正如我们本章论述的那样，不同的开发人员能够开发具有明显不同功能的独立子系统。例如：

发射器的飞行姿态和它在空间中的运动由惯性参照系统（SRI）测量。它具有自己内部的计算机，根据捷联式惯性平台的信息，通过激光陀螺和加速器计算角度和速度。来自SRI的数据通过数据总线传输到机载计算机（On-Board Computer，OBC），该计算机通过伺服阀门和液压执行器执行飞行程序、控制固体推进器的喷射器和Vulcain低温引擎（Lions et al. 1996）。

但是综合的解决方案必须包括一个具有所有构件的总体视图，它把各个部件合在一起考虑，以决定各部件之间的“联系”是否紧密、合适。在阿丽亚娜5的例子中，调查委员会提出客户和开发人员应该一起工作以找出关键软件，并确保它不仅能够处理预测到的行为，而且能够处理未预测到的行为。

这意味着，关键软件（从某种意义上来说，该软件的失效会使任务处于危险的境地）必须在一个非常详细的层面标识出来，异常行为必须细化，并且一个合理的备份策略必须将软件失效考虑进去（Lions et al. 1996）。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。