阿丽亚娜5号航班501的历史影响是什么？

阿丽亚娜5型火箭发射的在她的处女航（经过37秒解体飞行501）通常被称为一个历史上最昂贵的软件错误¹：

欧洲航天局花了10年时间和70亿美元，生产出了Ariane 5，这是一种巨型火箭，每次发射时都能将一对三吨重的卫星投向轨道，旨在使欧洲在商业航天领域具有压倒一切的优势。

去年6月首次航行不到一分钟，炸弹就爆炸了，在法属圭亚那的红树林沼泽中散落着炽热的瓦砾，这是一个小型计算机程序，试图将64位数字填充到16位空间中。

一个错误，一个崩溃。在计算机科学史册中记录的所有粗心代码行中，这一行可能是最具有毁灭性的高效代码。通过与火箭专家的访谈以及为航天局准备的分析，出现了从算术错误到彻底销毁的明确道路。

Flight 501的故障和随后的调查对安全关键系统和软件测试的研究产生了哪些重大变化？

我不是在寻找错误本身的解释，而是在从错误调查启发或直接与之相关的研究方面解释错误的历史影响。例如，本文得出以下结论：

我们使用静态分析来：

• 检查变量的初始化，
• 提供共享变量潜在数据访问冲突的详尽列表，
• 从Ada语义中详尽列出潜在的运行时错误。

据我们所知，这是首次使用基于布尔和基于非布尔的静态分析技术来验证工业程序。

同样，本文^（pdf）指出：

基于抽象解释的静态程序分析已用于对Ariane 5启动器和ARD的嵌入式ADA软件进行静态分析。静态程序分析器旨在自动检测运行时错误（例如标量和浮点溢出），数组索引错误，被零除和相关算术异常，未初始​​化的变量，共享数据结构等。分析仪能够自动发现Ariane 501的飞行错误。嵌入式安全关键软件（例如航空软件）的静态分析非常有前途。

对于这一事件对软件测试方法和工具的影响，我将进行详尽的解释。

_{¹这笔70亿美元的数字很可能是阿丽亚娜5号项目的总成本，维基百科报道，这次失败造成的损失超过3.7亿美元。失败仍然是一个相当昂贵的失败，但远不及70亿美元的数字。}

从技术上讲，它更多的是“ 软件腐烂 ”。飞行控制软件是从较早的Ariane 4火箭回收的，鉴于开发软件的成本很高，这是明智之举，尤其是当它的关键任务软件必须经过测试并验证的标准要比大多数商业软件所需的更为严格的标准时。

不幸的是，没有人打扰测试操作环境的变化会产生什么影响，或者如果没有这样做，他们就没有按照足够全面的标准进行测试。

该软件旨在防止某些参数永远不会超过某些值（推力，加速度，燃油消耗率，振动水平等）。在Ariane 4上的正常飞行中，这不是问题，因为如果没有明显的错误，这些参数将永远不会达到无效值。但是，阿丽亚娜5号要强大得多，在4号上看起来很傻的射程很容易在5号上发生。

我不确定是什么参数超出范围（它可能是加速，我必须检查），但是当它超出范围时，软件将无法应对，并遭受了算术溢出实施的错误检查和恢复代码不足。制导计算机开始向引擎喷嘴的万向节发送垃圾，垃圾再反过来开始随机地指向引擎喷嘴。火箭开始滚落并破裂，自动自毁系统检测到火箭现在处于一种不安全且无法恢复的姿态，从而完成了工作。

坦白地说，此事件可能没有汲取任何新的教训，因为以前在各种系统中都曾发掘过这类问题，并且已经存在处理和修复错误的策略。事件的发生使人们意识到，不遵守这些策略可能会产生巨大的后果，在这种情况下，数百万美元的硬件被破坏，一些客户极度恼火，并损害了阿丽亚娜航天公司的声誉。

这个特殊的案例特别耀眼，因为节省金钱的捷径最终导致金钱和声誉损失的巨额成本。如果该软件已经在Ariane 5模拟环境中经过了与最初为Ariane 4开发时一样强大的测试，那么肯定会在软件安装到启动硬件并投入使用之前很早就发现了错误。实际的飞行。此外，如果软件开发人员故意向软件中添加了一些废话，那么该错误甚至可能在Ariane 4时代就已经被抓住了，因为这可能会突出说明现有的错误恢复不充分的事实。

简而言之，它并没有真正教授新课程，但它使人们回想起不记得旧课程的危险。它还表明，软件系统在其中运行的环境与软件本身一样重要。仅仅因为该软件对于环境X是可验证的正确，并不意味着它适合于类似但独特的环境Y。最后，它强调了对于任务关键型软件而言，足够强大以应对不应该存在的情况至关重要发生了

将航班501与阿波罗11号及其计算机问题进行对比。LGC软件在着陆期间遇到严重故障，但其设计却非常坚固，尽管触发了软件警报，但仍能够保持运行状态，而不会使任何宇航员处于危险之中，并且仍然能够完成任务。

它主要是重用问题和管理问题，而不是编码问题。从我的回忆中（我很可能弄错了）该报告。

• 为Ariane IV设计了一个子系统。Ariane IV的轨迹无法导致溢出，因此，有意断定，如果发生溢出，这是硬件问题，关闭子系统并进行备用操作是正确的选择。

• 对于Ariane V，决定重用该子系统，而不是复查假设和代码，而是依靠测试。

• 进一步决定放弃全面测试。

阿丽亚娜五号的不同飞行参数造成了溢出。关闭主服务器。关闭备用零件。自毁。

我还记得其他事情：

• 溢出时的子系统不再有用。有人可能会说它的失败不应该触发自毁。（另一方面，增加的复杂性本身可能是问题的根源）。

• 在不应该将调试数据发送到总线的情况下。我不记得具体。

正如其他人所提到的，这使整个行业重新审视了重用的概念，并将其置于更大的参考框架中，在该框架中，不是孤立地评估组件，而是在整个系统的上下文中对其进行评估。这会极大地降低重复使用的吸引力，因为即使某个组件无需更改即可重复使用，仍然必须使用一组新的假设对其进行分析。另一个推论是，运行相同软件的备用硬件吸引力不大，因为大多数现代硬件的可靠性要比现代软件高几个数量级。我听说有些国防合同要求由不同的团队使用不同的技术开发的两个单独的软件系统，这些技术应使用相同的规范来验证正确的实施。