专业/阿丽亚娜 5 号 501 航班

阿丽亚娜 501 集群

事件

1996 年 6 月 4 日，欧洲航天局发射了阿丽亚娜 5 号火箭，501 航班从法属圭亚那库鲁发射。火箭的目标是将商业有效载荷发射到轨道，特别是四颗星群卫星。这些卫星将被放置在高椭圆轨道上，以对地球的磁层进行研究，从而使欧洲在商业太空业务中占据主导地位。欧洲航天局花了 10 年时间和 70 亿美元生产了这枚火箭。

那天，该局在建造火箭上投入的所有努力都付诸东流，包括 3.7 亿美元，发射器偏离了飞行路径，解体并爆炸，发射序列开始后仅约 40 秒，在 3700 米的高度上爆炸，将燃烧的碎片散落在法属圭亚那。幸运的是，没有人员伤亡。来自阿丽亚娜 5 号项目的 CNES 和工业团队的工程师立即开始调查故障，一个小型的计算机程序试图将一个 64 位数字塞入一个 16 位空间造成的。

由于向发动机发送了错误的控制信号，并在升空后 37 秒使火箭旋转，惯性参考系统（用于计算和引导火箭的速度、位置和方向）失效。火箭爆炸增加了地面和水中的氧化铝含量，损害了法属圭亚那沼泽的环境。

技术故障

阿丽亚娜 501 坠落区

事件发生后几天，成立了一个独立的调查委员会，其中一个结论是，由于惯性参考系统 (SRI)的规格和设计错误，发射器在主发动机点火序列开始后 37 秒失去了制导和高度信息。调查委员会发现，SRI 软件中的以下设计缺陷导致了501 航班的失败：升空后维护的预发射功能（对准模式）与飞行不兼容。在备用SRI（正在待命，用于制导和姿态控制）内的计算机失效后约 0.05 秒，正在使用的SRI（硬件和软件与备用系统相同）由于相同的原因失效。由于备用惯性系统已经失效，因此无法获得正确的制导和姿态信息。由于备用SRI失效，正在使用的SRI向发射器的主计算机发送了诊断信息，主计算机将其解释为飞行数据，并将其用于飞行控制计算。根据这些计算，主计算机命令助推器喷嘴和主发动机喷嘴对未发生的升高度偏差进行大幅度修正。由于气动力，由此产生的快速升高变化导致发射器在主发动机点火序列开始后 39 秒解体。按照设计，解体后自动启动销毁。

所有其他证明有效的程序测试和审查都没有发现这些异常，并且地面/飞行模式接口没有得到充分识别。NASA 天体物理学数据系统提供的一篇来自欧洲航天局的论文解释说，501 航班的惯性测量单元程序由于代码片段（飞行阶段未使用）而失败，因此，彻底识别死代码和未使用的但活跃代码，并证明未使用的可执行代码永远不会导致运行时错误非常重要。

尽管在阿丽亚娜 5 号开发计划期间进行了广泛的审查和测试，但它们没有包括对SRI 或完整飞行控制系统的充分分析和测试，这本可以检测到潜在的故障。该机构错误地认为，由于SRI适用于阿丽亚娜 4 号，因此它也适用于阿丽亚娜 5 号，而阿丽亚娜 5 号的技术规格不同。

现状偏差

随着 100 多次成功发射，阿丽亚娜 4 号成为ESA历史上最成功的火箭之一。它服役了 20 多年，被称为ESA发射器舰队的“主力”。阿丽亚娜 5 号项目团队的任务是设计阿丽亚娜 4 号的继任者。新火箭必须在不影响可靠性的前提下，超越其前身的有效载荷能力。

考虑到阿丽亚娜 4 号的成功，从事阿丽亚娜 5 号工作的工程师开始从阿丽亚娜 4 号项目中借用主要部件，包括阿丽亚娜 4 号的软件包。阿丽亚娜 4 号的大部分软件被设计为“黑盒子”，这意味着它可以在不同的发射器中重复使用，而无需进行重大修改。阿丽亚娜 5 号工程师从制导控制系统到飞行路径优化软件，都进行了回收，因为阿丽亚娜 4 号的软件包拥有 100% 的成功率。

阿丽亚娜 4 号的组件实质上成为现状。在设计新系统和使用阿丽亚娜 4 号组件之间，工程师选择了更轻松、更便宜的途径。重新设计系统意味着要对该系统的成功负责。工程师不想改变他们认为已经有效的东西，最终借用了太多东西。

导致501 号航班失败的软件是从阿里安 4 号借来的。它不像阿里安 5 号工程师想象的那样适应性强，而且没有按预期工作。工程师对SRI寄予了过高的期望。为了避免额外的风险，阿里安 5 号设计团队无意中做出了一个导致火箭灾难性失败的决定。

责任分散

阿里安 5 号501 号航班爆炸代表了一种责任分散，因为没有人或团队对灾难负责。法国和欧洲航天局成立的独立调查委员会发布的报告指出，五个分别在航天器上工作的团队本可以防止爆炸。这些团队是

• 程序员：更好的编程实践可以防止由将 64 位浮点数转换为 16 位有符号整数值导致的软件错误。
• 设计师：更好的设计，不允许软件异常停止正常运行的硬件单元，可以防止SRI关闭。
• 需求工程师：更好的需求分析和可追溯性可以防止来自早期阿里安型号的对齐代码的异常部分被激活，导致航天器故障。
• 测试工程师：一项测试验证SRI在受到阿里安 5 号飞行序列和轨迹影响时是否能正常工作，将暴露故障。
• 项目经理：改进的项目管理流程，促进更紧密的工程合作，明确的权限和责任，以及一致的代码和文档，将增加暴露故障的可能性。

虽然许多团队都可能受到指责，但欧洲调查人员选择不单独指认任何特定承包商或部门。他们说，“一个决定已经做出。它没有得到充分的分析或理解。在飞行过程中让它继续运作的可能后果没有被意识到。”

偏差的正常化

如果工程师有更积极的测试程序，错误可能会及时被发现。然而，工程师在设计测试过程中采取了捷径，这是为了应对一系列全面预算削减。欧空局指定了非常严格的软件测试程序，旨在发现导致501 号航班坠毁的那类问题，但它们没有被遵守。就像挑战者号灾难一样，冒险行为逐渐成为常态。

当工程师测试阿里安 5 号软件包时，成本是他们决策中的一个重要因素。工程师有两个选择

1. 进行一次完整的模拟发射，同时测试所有软件。
2. 进行一些独立的测试，只测试软件子系统。

该团队选择了第二种方案，因为它比第一种方案便宜得多。由于软件是独立测试的，导致501 号航班失败的故障没有被发现。

削减成本促使在阿里安 5 号的软件设计中使用了有风险的测试程序。事故发生后，调查委员会的分析显示，该软件包的主要组件充满了被忽视的错误。由于软件代表了一个单点故障，冗余系统难以实现，因此通过测试尽职尽责尤为重要。阿里安 5 号软件工程师未能尽职尽责。

未来

欧洲调查委员会调查了这场灾难，并对如何防止灾难提出了一些建议。在调查委员会提出的 14 项建议中，特别是第 12 至 14 项建议，指的是流程中的缺陷或故障。这三项建议说明了飞行是如何失败的，以及如何防止未来发生类似的失败。

• 建议 12：“对证明文档的重视程度与代码相同。改进保持代码及其证明一致的技术。”
• 建议 13：“成立一个团队，制定软件资格认证程序，提出严格的确认资格认证的规则，并确保阿里安 5 号项目的软件规范、验证和测试始终保持高质量。应考虑包括外部RAMS专家。”
• 建议 14：“必须考虑更透明地组织阿里安 5 号项目合作伙伴之间的合作。需要进行紧密的工程合作，明确的权限和责任，以实现系统协调，合作伙伴之间拥有简单明了的接口。”

展望未来，这三项建议将有助于促进更加协调、清晰和专业的合作环境，以减轻未来的混乱。

概括

从阿里安 5 号501 号航班灾难中吸取的教训可以推广到其他案例。首先，即使是最小的细节也至关重要，并可能产生巨大的后果。64 位浮点数的转换错误导致了价值数百万美元的巨大航天器的爆炸。在许多系统中，小细节与大细节一样重要。

其次，除了测试系统应该做什么，还应该测试系统不应该做什么。如果系统测试了浮点数转换失败的情况，那么导致爆炸的错误本可以被发现。测试不应该发生的情况可以提高可靠性。

第三，权限和责任应该明确。没有人对导致501 号航班爆炸的错误负责。当没有人对故障负责时，更难找到问题，也更难避免未来出现问题。当团队成员之间的职责明确时，更容易发现问题，沟通和合作也会得到改善。

第四，不要设计一个系统，其中单个组件故障会导致整个系统故障 - 单点故障。对于航班 501，软件错误不仅导致SRI（一个软件系统）故障，还导致了整个航天器的爆炸。一个系统中一个故障不会导致整个系统崩溃，这样更可靠也更安全。