《软件工程(第4版?修订版)》—第1章1.10节实时系统的例子

本节书摘来自异步社区《软件工程(第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)。

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

上一篇:gearman实现redis缓存mysql


下一篇:面试官就是这么欺负人:new Object()到底占用几个字节?