星簇卫星
阿丽亚娜V88飞行(Ariane flight V88)[1]是1996年6月4日阿丽亚娜航天公司阿丽亚娜-5运载火箭首次失败的发射,该枚编号为501的运载火箭搭载了四颗由欧洲航天局研究卫星所组成的卫星群。
测试中的星簇卫星 | |
任务类型 | 磁层探测 |
---|---|
运营方 | 欧空局 |
航天器属性 | |
發射質量 | 1200千克(2600磅) |
任務開始 | |
發射日期 | 1996年6月4日 12:34:06 (UTC) |
运载火箭 | 阿丽亚娜5G型火箭 |
發射場 | 库鲁航天中心3号发射台 |
任務終止 | |
丟棄形式 | 发射失败 |
毀損日期 | 1996年6月4日 |
由于软件设计中的多个错误,发射以失败告终:对整数溢出保护不足的死代码(其运行仅有效于阿丽亚娜4号运载火箭),导致异常处理不当—停止整个惯性导航系统(否则就不会受到影响)。使火箭在发射37秒后偏离飞行轨道,在高空气动力作用下开始解体,最后通过自动飞行终止系统自毁。这一惨痛的失败成为历史上最著名、代价最昂贵的软件漏洞之一[2],这次失败造成的损失超过3.7亿美元[3]。
发射失败
阿丽亚娜5型火箭沿用了阿丽亚娜4型惯性导航平台的代码,但两者的不同之处在于阿丽亚娜5型火箭早期飞行阶段的水平速度更高,这导致校准函数计算出的内部水平偏差值(BH)出乎意料地高。根据阿丽亚娜4型的需求,校准函数可运行约40秒的飞行时间。阿丽亚娜5号升空后校准函数实际不起任何作用[4],但更高的水平偏差值导致数据被从64位浮点数转换成16位符号整数值,引发数据溢出和硬件异常[5]:
P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)))
由于担心星载计算机运算能力的限制,软件开发前,程序员仅保护了七个关键变量中的四个免于溢出,并依赖三个未保护变量错误的假定取值范围(尽管这些假设对阿丽亚娜4型火箭轨迹是正确的)[6]。该异常使两个惯性导航系统模块停止运行,虽然它们原本为冗余的。主动模块向星载计算机提交了被解释为飞行数据的诊断数位模式,尤其引起固体助推器和武尔坎主引擎喷嘴完全偏转,使攻角超过20度,进而造成助推器与主火箭分离,触发火箭自毁系统并中断飞行[4]。
根据威廉·卡汉的说法,如果使用默认的IEEE 754异常处理策略(“预替代”),就可避免501号发射的损失,因为它不会中止计算[7]。关于坠毁事件的官方报告(由雅克·路易斯·利昂领导的调查委员会进行)指出,“阿丽亚娜5号开发的一个基本思路是倾向减少随机故障。惯性导航系统(SRI)的供应商只是遵循了给定的规范,即一旦检测到任何异常,就立即停止处理器工作。但这次发生的异常并非由于随机故障而是设计错误所产生。异常虽被检出,但处理并不恰当,因为直到故障出现前,该软件一直被认为是正确的[...]。尽管故障是由于系统软件设计错误造成,但可以引入机制来缓解此类问题。例如,惯性导航系统内的电脑应能继续提供所需姿态信息的最佳估测。允许甚至要求在软件异常时停止正在处理任务关键设备处理器的这一模式令人担忧。事实上,失去适当的软件功能非常危险,因为相同的软件在两台惯导单元中运行。在阿丽亚娜501火箭的案例中,它导致了两台仍正常的关键设备被关闭” [4]。
报告确认的有关测试的其他问题[4]:
- 对所有参与阿丽亚娜5型运载火箭计划主要合作方的审查只是验证其设计决策并获得飞行资格。在此过程中,并未充分分析校准软件的局限性,也未意识到它在飞行过程中继续运行产生的可能影响。
- 惯性导航系统的规范和在设备层面进行的测试并未具体包括阿丽亚娜5型轨道数据。因此,没有在模拟阿丽亚娜5型飞行条件下对重新校准功能进行测试,也没有发现设计错误。
- 将惯性导航系纺全部纳入整个系统仿真在技术上是可行的,但出于多种原因,最终决定只使用惯导系统的模拟输出,而非真实系统或对其详细模拟。如果当时将整个系统包含在内,则故障就可能被检出。后来在计算机中利用惯性导航系统软件和包括阿丽亚娜501号实际飞行轨迹数据等模拟环境进行的仿真飞行,真实地再现了导致惯性导航系统失效的事件过程。
- 水平速度和由此计算出的水平偏差数值等变量范围应明确量化,而实际情况是,仅假定为16位范围。
- 校准任务应在适当的时候停用,实际情况是,起飞后就开始运行。
- 应分析惯性导航平台的故障模型,以确保在整个飞行过程中能持续服务,而非只假定最多一台仪器会失效。现实情况是两台仪器都出现了故障,输出的诊断信息被解释为飞行数据,而不是正常终止飞行。
有效载荷
星簇卫星由四颗重1200公斤(2600磅)、安装有224瓦供电太阳能板的圆柱形自旋稳定航天器组成。四颗卫星将以四面体的形式飞行,旨在对地球磁层进行研究。卫星将被插入到17200x120600公里(10700x74900英里),朝赤道倾斜90度的高椭圆轨道上[9]。
后果
故障发生之后,又建造了四颗替代的星簇2号卫星。2000年,它们搭载在联盟-U/佛盖特火箭上被成对发射升空。
发射失败使与复杂计算系统相关的高风险引起了公众、政界人士和高管层的重视,从而增加了对确保安全攸关系统可靠性研究的支持。随后对阿丽亚娜代码(用Ada语言编写)的自动分析是首个通过抽象解释进行大规模静态代码分析的示例[10]。
这一失败也损害了欧洲航天局火箭系列的优异发射记录,这是由阿丽亚娜4型的高成功率所创造的。直到2007年,阿丽亚娜5型火箭才被公认为与以前的型号一样可靠[11] 。
另请查看
- 火星气候探测者号从早期火星气候轨道器改编的软件在发射前没有经过充分测试。
- 阿波罗制导计算机—阿波罗主要制导、导航和控制系统(PGNCS)故障,航天器导航计算机因子系统不适当地保持运行而受到影响。
参考文献
- . www.capcomespace.net. [2021-12-25]. (原始内容存档于2021-05-27).
- Gleick, James. . New York Times Magazine. 1 December 1996 [7 April 2012]. (原始内容存档于2012-04-20).
- Dowson, Mark. . ACM SIGSOFT Software Engineering Notes. March 1997, 22 (2): 84. S2CID 43439273. doi:10.1145/251880.251992.
- . [2014-07-16]. (原始内容存档于2014-04-26).
- Nuseibeh, Bashar. (PDF). IEEE Software. May 1997, 14 (3): 15–16 [2021-12-26]. S2CID 206482665. doi:10.1109/MS.1997.589224. (原始内容存档 (PDF)于2021-11-17).
- . www.irisa.fr. [5 May 2018]. (原始内容存档于4 June 2016).
- W.Kahan. (PDF). July 5, 2005. (原始内容存档 (PDF)于March 10, 2012).
- Le Lann, Gérard. . . IEEE Computer Society: 339–346. March 1997. ISBN 0-8186-7889-5. doi:10.1109/ECBS.1997.581900.
- Krebs, Gunter. . Gunter's Space Page. [29 November 2011]. (原始内容存档于2021-10-23).
- Faure, Christèle. . [3 October 2010]. (原始内容存档于2011-07-21).
- Todd, David. . March 2007.
延伸阅读
- Thomas, L.D. (2007) Selected Systems Engineering Process Deficiencies and their Consequences. Acta Astronautica, 61, 406–415.
外部链接
- 雅克·路易斯·利昂等人,阿丽亚娜501号调查委员会报告 (页面存档备份,存于)
- 实现航天飞行网-星簇2号-阿丽亚娜501号爆炸,存档于(存檔日期 25 March 2015).直接链接到视频文件 — 火箭飞行最后几秒钟的镜头。
- 连线杂志一历史上最严重的软件漏洞 (页面存档备份,存于)——篇关于前10大软件缺陷的文章。阿丽亚娜5型火箭501号飞行软件故障被认为是其中之一。
- (德語) 阿丽亚娜5型-501(1-3) (页面存档备份,存于)-一篇好文章(德语),其中给出了问题中的实际代码。