#013 · Ariane 5 Explosion · Short Articles

On 4 June 1996, Europe's new heavy-lift rocket cleared the jungle canopy at Kourou, flew for thirty-seven seconds, and tore itself apart. The cause was a line of Ada code written for a different rocket a decade earlier.

The Ariane 5 sat on pad ELA-3 at the Centre Spatial Guyanais in French Guiana, fuelled and counting down for the first time. On board were four identical satellites for the Cluster mission, a European Space Agency programme to study how the solar wind interacts with the Earth's magnetosphere. Each one was the product of about a decade of work. The launcher itself had cost the agency roughly seven billion dollars and ten years of development. Liftoff came at 12:34 UTC. The rocket climbed clean, rolled onto its planned heading, and for thirty-six seconds did exactly what it was meant to do.

At T+36.7 seconds, while passing through a horizontal velocity higher than anything the older Ariane 4 had ever seen at that point in flight, the active inertial reference system on board detected what it interpreted as a catastrophic internal fault and shut itself down. Control passed to the backup unit, which had already failed for the same reason seventy-two milliseconds earlier. With no navigation data, the on-board computer interpreted diagnostic bit patterns from the dead inertial system as flight data and commanded the engine nozzles to full deflection. The rocket pitched over hard, aerodynamic loads ripped the boosters from the core stage, and the range safety system triggered self-destruct at T+39 seconds. About half a billion dollars of hardware rained into the mangrove swamp.

Ariane 5 / ATV-4 'Albert Einstein' DLR_de · BY 2.0

A seven-line conversion

The Lions Commission, chaired by the French mathematician Jacques-Louis Lions, reported six weeks later. The report is one of the cleanest forensic documents in software engineering. The fault lay in the Inertial Reference System, the SRI, whose software had been inherited wholesale from Ariane 4. Inside the SRI, a routine measured the rocket's horizontal bias — a value useful only before liftoff, to align the platform. It converted a 64-bit floating-point number representing that bias into a 16-bit signed integer. On Ariane 4, the horizontal velocities reached during the alignment window never exceeded the 32,767 ceiling of a signed 16-bit integer. On Ariane 5, with a steeper, faster trajectory, they did.

Ariane 5 stands on its launch pad at the edge of the French Guiana jungle before dawn Illustration · AI-generated (FLUX.1-dev)

The conversion was written in Ada and, by language design, raised an Operand Error when the float overflowed. Seven variables in the module were candidates for protection against such errors. Three were left unprotected on the explicit grounds that analysis had shown the values could never exceed safe limits — analysis carried out for Ariane 4. The horizontal-bias variable was one of the three. When the exception fired, the handler dumped the SRI's internal state to the data bus and halted the processor. The backup SRI, running identical code on identical inputs, had halted the same way a few cycles earlier. The on-board computer read the diagnostic dump as if it were attitude data. Everything downstream followed inevitably.

Ariane 5 with James Webb Space Telescope Prelaunch James Webb Space Telescope · BY 2.0

Worse: the alignment routine had no business still running. It existed only to handle a contingency in the Ariane 4 countdown, where a late hold might require the inertial platform to re-align without restarting the sequence. Ariane 5's countdown procedure had no such contingency. The code was active during flight purely because nobody had stripped it out.

The rocket lifts cleanly from the pad Illustration · AI-generated (FLUX.1-dev)

What the review missed

The Lions report is unsparing about why none of this was caught. The SRI had been qualified in isolation against a specification that did not include the Ariane 5 trajectory. The full flight software had been tested in a closed-loop simulation, but the SRI itself was substituted with a simulator rather than the real unit, on the grounds that the real unit's behaviour was already known. The horizontal-bias variable's actual flight values were never fed through the real conversion code on the ground. The launcher's first encounter with its own trajectory was the launch.

Webb’s Ariane 5 core stage made ready James Webb Space Telescope · BY 2.0

There is a temptation, reading this, to file the disaster under "integer overflow" and move on. The deeper lesson the commission drew was about reuse. Components qualified for one vehicle were assumed to be qualified for another because the interfaces matched. The assumption was reasonable. It was also wrong, and the chain of reviewers who could have questioned it each had a defensible reason not to.

A clean-room avionics bench holds an inertial reference unit removed from a launch vehicle Illustration · AI-generated (FLUX.1-dev)

What we still don't know

We know what the bug was. What is less clear is why a 1996 launcher was still flying code paths that existed only to serve a 1980s countdown procedure. Documentation from the original Ariane 4 SRI development is thin, and some of the people who made the original design decisions had retired.

We do not know, in any quantified way, how often this pattern recurs in flight-qualified avionics today. The post-Ariane-5 reforms at ESA produced a cleaner development standard, ECSS, but the underlying problem — reused components carrying implicit assumptions about their host vehicle — is a question of culture as much as process, and culture is hard to audit.

High above the jungle Illustration · AI-generated (FLUX.1-dev)

And we do not know how many near-misses have been quietly absorbed since. Launch failures are visible. A converted integer that happened to fit because the trajectory was a fraction shallower is not.

The four Cluster satellites were rebuilt from spares and launched on Soyuz rockets in 2000. They worked, in formation, for more than twenty years. The flight software for Ariane 5's next launch removed the alignment routine entirely.

1996年6月4日，欧洲的新型重型运载火箭掠过库鲁的丛林树冠，飞行三十七秒后，在空中自行解体。起因竟是十年前为另一枚火箭编写的一行 Ada 代码。

阿里安5号运载火箭静候在法属圭亚那Centre Spatial Guyanais的ELA-3发射台上，燃料已加注完毕，正进行首次发射倒计时。火箭上搭载着四颗完全相同的卫星，隶属于Cluster mission，这是欧洲空间局一项旨在研究太阳风与地球磁场相互作用的计划。每一颗卫星都是约十年辛勤工作的结晶。而火箭本身则耗费了该机构大约70亿美元和十年的研发时间。升空发生在协调世界时12:34。火箭平稳上升，转向预定航向，在最初的36秒内表现得完全符合预期。

在T+36.7秒时，当火箭的水平速度超过了老旧的Ariane 4在飞行同阶段所经历的任何数值时，机载的主惯性基准系统监测到了它认为是灾难性的内部故障，并随即自行关闭。控制权移交给了备份单元，而该单元在72毫秒前也因同样的原因发生了故障。在缺乏导航数据的情况下，机载计算机将来自已失效惯性系统的诊断位模式解读为飞行数据，并向发动机喷管发出了全偏转指令。火箭剧烈倾斜，气动载荷将助推器从芯级上撕裂，靶场安全系统在T+39秒触发了自毁程序。价值约5亿美元的硬件如雨点般坠入红树林沼泽。

七行代码的转换

六周后，由法国数学家雅克-路易·利昂主持的Lions Commission发布了调查报告。这份报告是软件工程领域最清晰、最精准的取证分析文件之一。故障源于惯性基准系统（即SRI），其软件完全沿袭自阿里安4号。在SRI内部，有一个例程负责测量火箭的水平偏置——这一数值仅在升空前有用，用于校准平台。它将代表该偏置的64位浮点数转换为16位有符号整数。在阿里安4号上，校准窗口期间达到的水平速度从未超过16位有符号整数32,767的上限。而在弹道更陡、速度更快的阿里安5号上，情况则不同了。

这一转换过程是用Ada编写的。根据该语言的设计，当浮点数发生溢出时，会触发“操作数错误”（Operand Error）。该模块中有七个变量原本需要针对此类错误进行保护。其中三个变量未被保护，理由是之前的分析表明其数值绝不会超过安全限值——而那项分析是针对阿里安4号进行的。水平偏置变量正是这三个变量之一。当异常被触发时，处理程序将SRI的内部状态转储到数据总线并停止了处理器运行。运行着相同代码、接收着相同输入的备份SRI，在几个周期前已以同样的方式宕机。机载计算机将诊断转储数据误当成了姿态数据。随后发生的一切便成了必然。

更糟糕的是：校准例程本就不该继续运行。它的存在仅是为了处理阿里安4号倒计时中的一种偶发情况，即在倒计时后期暂停时，可能需要惯性平台在不重启序列的情况下重新校准。阿里安5号的倒计时流程中并没有这种设定。这段代码在飞行过程中仍然保持活跃，纯粹是因为没有人将其移除。

评审遗漏了什么

利昂报告对为何未能察觉这些隐患进行了毫不留情的剖析。SRI是在孤立状态下通过认定的，其遵循的规范并未包含阿里安5号的飞行弹道。完整的飞行软件曾在闭环模拟中进行过测试，但SRI本身却被模拟器而非实物单元所替代，理由是实物单元的行为已被公认为已知。水平偏置变量在实际飞行中的数值，从未在地面上通过真实的转换代码进行过测试。火箭第一次接触到自己的飞行弹道，就是在发射那一刻。

读到这里，人们很容易将这场灾难简单归类为“整数溢出”然后就此揭过。然而，委员会总结出的更深层教训关乎“重用”。仅因接口匹配，人们便理所当然地认为适用于某一载具的组件也同样适用于另一载具。这一假设合乎逻辑，但它也是错误的，而那些本可以提出质疑的评审链条上的每一个人，都有着合理的理由不这么做。

我们依然未知的

我们知道漏洞是什么。但不太清楚的是，为什么一枚1996年的运载火箭仍在运行仅为1980年代倒计时流程服务的代码路径。最初阿里安4号SRI研发阶段的文档资料非常匮乏，而一些做出原始设计决策的人员也已经退休。

我们无法以任何量化的方式得知，这种模式在当今通过飞行认定的航电系统中发生的频率。阿里安5号事件后，欧空局的改革催生了更严谨的开发标准ECSS，但潜在的问题——即重用组件带有的关于宿主载具的隐性假设——既是流程问题，也是文化问题，而文化是难以审计的。

我们也不知道自那以后，有多少类似的险情被悄无声息地化解了。发射失败是显而易见的。但一个因为弹道稍微平缓一点而侥幸没有溢出的转换整数，却无人察觉。

四颗Cluster卫星由备件重新建造，并于2000年搭乘联盟号火箭升空。它们以编队形式运行了二十多年。阿里安5号下一次发射的飞行软件彻底移除了校准例程。

El 4 de junio de 1996, el nuevo cohete de carga pesada de Europa rebasó el dosel de la selva en Kourou, voló durante treinta y siete segundos y se despedazó. La causa fue una línea de código Ada escrita para un cohete distinto una década antes.

El Ariane 5 aguardaba en la plataforma ELA-3 del Centre Spatial Guyanais, en la Guayana Francesa, con los tanques llenos y la cuenta regresiva en marcha por primera vez. A bordo viajaban cuatro satélites idénticos para la Cluster mission, un programa de la Agencia Espacial Europea destinado a estudiar la interacción del viento solar con la magnetosfera terrestre. Cada uno era el fruto de aproximadamente una década de trabajo. El propio lanzador le había costado a la agencia unos siete mil millones de dólares y diez años de desarrollo. El despegue se produjo a las 12:34 UTC. El cohete ascendió limpiamente, giró hacia el rumbo previsto y, durante treinta y seis segundos, hizo exactamente aquello para lo que había sido diseñado.

Al llegar al segundo T+36,7, mientras alcanzaba una velocidad horizontal superior a cualquier registro previo del antiguo Ariane 4 en ese punto del vuelo, el sistema de referencia inercial activo detectó lo que interpretó como un fallo interno catastrófico y se apagó. El control pasó a la unidad de reserva, que ya había fallado por el mismo motivo setenta y dos milisegundos antes. Sin datos de navegación, la computadora de a bordo interpretó los patrones de bits de diagnóstico del sistema inercial inerte como datos de vuelo y ordenó la deflexión total de las toberas del motor. El cohete cabeceó bruscamente, las cargas aerodinámicas arrancaron los propulsores de la etapa central y el sistema de seguridad de vuelo activó la autodestrucción en el segundo T+39. Unos quinientos millones de dólares en equipo llovieron sobre el manglar.

Una conversión de siete líneas

La Lions Commission, presidida por el matemático francés Jacques-Louis Lions, presentó su informe seis semanas después. El documento es una de las piezas forenses más nítidas de la ingeniería de software. El fallo residía en el Sistema de Referencia Inercial, el SRI, cuyo software se había heredado íntegramente del Ariane 4. Dentro del SRI, una rutina medía el sesgo horizontal del cohete, un valor útil solo antes del despegue para alinear la plataforma. La rutina convertía un número de punto flotante de 64 bits que representaba dicho sesgo en un entero con signo de 16 bits. En el Ariane 4, las velocidades horizontales alcanzadas durante la ventana de alineación nunca superaban el límite de 32.767 de un entero de 16 bits. En el Ariane 5, con una trayectoria más empinada y rápida, sí lo hicieron.

La conversión estaba escrita en Ada y, por diseño del lenguaje, generaba un Error de Operando cuando el valor flotante se desbordaba. Siete variables del módulo eran candidatas a ser protegidas contra tales errores. Tres se dejaron desprotegidas bajo el argumento explícito de que los análisis previos demostraban que los valores nunca superarían los límites de seguridad; análisis realizados para el Ariane 4. La variable del sesgo horizontal era una de esas tres. Cuando saltó la excepción, el controlador volcó el estado interno del SRI al bus de datos y detuvo el procesador. El SRI de reserva, que ejecutaba el mismo código con los mismos datos de entrada, se había detenido de igual forma unos ciclos antes. La computadora de a bordo leyó el volcado de diagnóstico como si fuesen datos de actitud. Todo lo que ocurrió después fue una consecuencia inevitable.

Peor aún: la rutina de alineación no tenía por qué seguir ejecutándose. Existía únicamente para gestionar una contingencia en la cuenta regresiva del Ariane 4, en la que una interrupción tardía podría requerir que la plataforma inercial se realineara sin reiniciar la secuencia. El procedimiento de cuenta regresiva del Ariane 5 no contemplaba tal contingencia. El código estaba activo durante el vuelo simplemente porque nadie lo había eliminado.

Lo que la revisión pasó por alto

El informe Lions es implacable al explicar por qué nada de esto se detectó. El SRI había sido calificado de forma aislada bajo una especificación que no incluía la trayectoria del Ariane 5. El software de vuelo completo se había probado en una simulación de bucle cerrado, pero el SRI propiamente dicho fue sustituido por un simulador en lugar de la unidad real, alegando que el comportamiento de esta ya era conocido. Los valores reales de vuelo de la variable de sesgo horizontal nunca pasaron por el código de conversión real en tierra. El primer encuentro del lanzador con su propia trayectoria fue el lanzamiento.

Al leer esto, surge la tentación de archivar el desastre bajo la etiqueta de «desbordamiento de entero» y pasar a otra cosa. La lección más profunda que extrajo la comisión trataba sobre la reutilización. Se asumió que los componentes calificados para un vehículo lo estaban también para otro porque las interfaces coincidían. La suposición era razonable. También era errónea, y la cadena de revisores que podrían haberla cuestionado tenía, cada uno, un motivo defendible para no hacerlo.

Lo que todavía ignoramos

Sabemos cuál fue el error. Lo que resulta menos claro es por qué un lanzador de 1996 seguía ejecutando rutas de código que existían solo para dar servicio a un procedimiento de cuenta regresiva de los años ochenta. La documentación del desarrollo original del SRI del Ariane 4 es escasa, y algunas de las personas que tomaron las decisiones de diseño iniciales ya se habían jubilado.

No sabemos, de ninguna forma cuantificada, con qué frecuencia se repite este patrón en la aviónica calificada para el vuelo en la actualidad. Las reformas posteriores al Ariane 5 en la ESA dieron lugar a un estándar de desarrollo más limpio, el ECSS, pero el problema de fondo —componentes reutilizados que arrastran suposiciones implícitas sobre su vehículo anfitrión— es una cuestión tanto de cultura como de proceso, y la cultura es difícil de auditar.

Y no sabemos cuántos incidentes similares se han absorbido discretamente desde entonces. Los fallos de lanzamiento son visibles. Un entero convertido que, por azar, encajó porque la trayectoria fue una fracción más plana, no lo es.

Los cuatro satélites Cluster se reconstruyeron a partir de repuestos y se lanzaron en cohetes Soyuz en el año 2000. Funcionaron, en formación, durante más de veinte años. El software de vuelo para el siguiente lanzamiento del Ariane 5 eliminó por completo la rutina de alineación.

في الرابع من يونيو ١٩٩٦، تجاوز صاروخ أوروبا الجديد المخصص للأحمال الثقيلة هامة الغابة في "كورو"، وحلّق لسبع وثلاثين ثانية قبل أن يتمزق إرباً. كان السبب سطراً برمجياً بلغة "آدا"، كُتب لصاروخٍ آخر قبل عقدٍ من الزمان.

استقرت "أريان 5" على منصة "ELA-3" في Centre Spatial Guyanais في غويانا الفرنسية، وقد زُوّدت بالوقود وبدأ عدُّها التنازلي للمرة الأولى. كان على متنها أربعة أقمار صناعية متطابقة لبعثة Cluster mission، وهو برنامج تتبعه وكالة الفضاء الأوروبية لدراسة كيفية تفاعل الرياح الشمسية مع الغلاف المغناطيسي للأرض. كان كل قمر منها نتاج نحو عقد من العمل، أما منصة الإطلاق نفسها فقد كلفت الوكالة قرابة سبعة مليارات دولار وعشر سنوات من التطوير. انطلق الصاروخ في تمام الساعة 12:34 بالتوقيت العالمي المنسق، وصعد في مسار نقي، ثم مال نحو وجهته المخطط لها، وظل لست وثلاثين ثانية يفعل بالضبط ما كان مقدراً له أن يفعله.

وفي اللحظة "ت + 36.7" ثانية، وبينما كان الصاروخ يتجاوز سرعة أفقية أعلى من أي سرعة شهدتها "Ariane 4" القديمة في تلك المرحلة من الطيران، اكتشف نظام المرجع العطالي النشط على المتن ما فسره على أنه خطأ داخلي كارثي، فأوقف نفسه عن العمل. انتقل التحكم إلى الوحدة الاحتياطية، التي كانت قد تعطلت بالفعل للسبب نفسه قبل اثنتين وسبعين ميلي ثانية. ومع غياب بيانات الملاحة، فسر الكمبيوتر الموجود على المتن أنماط بت التشخيص القادمة من النظام العطالي المتوقف على أنها بيانات طيران، وأعطى أمراً لفوهات المحرك بالانحراف الأقصى. مال الصاروخ بشدة، واقتلعت الأحمال الديناميكية الهوائية المعززات من المرحلة المركزية، ليُفعل نظام سلامة المدى التدمير الذاتي في اللحظة "ت + 39" ثانية. وهكذا، انهمر ما قيمته نصف مليار دولار تقريباً من الأجهزة كالمطر فوق مستنقعات المانغروف.

تحويل من سبعة أسطر

أصدرت Lions Commission، برئاسة عالم الرياضيات الفرنسي جاك لوي ليونز، تقريرها بعد ستة أسابيع. ويُعد هذا التقرير واحداً من أوضح الوثائق الفاحصة في تاريخ هندسة البرمجيات. كمن الخلل في نظام المرجع العطالي، المعروف اختصاراً بـ SRI، الذي ورث برمجياته بالكامل من "أريان 4". وداخل هذا النظام، كان هناك روتين يقيس الانحياز الأفقي للصاروخ، وهي قيمة لا تفيد إلا قبل الانطلاق لمحاذاة المنصة. كان الروتين يحول رقماً بفاصلة عائمة بسعة 64 بت يمثل ذلك الانحياز إلى عدد صحيح مُشار بسعة 16 بت. وفي "أريان 4"، لم تكن السرعات الأفقية التي يتم الوصول إليها خلال نافذة المحاذاة تتجاوز أبداً سقف الـ 32,767 الذي يحتمله العدد الصحيح بسعة 16 بت، أما في "أريان 5"، وبسبب مسارها الأكثر حدة وسرعة، فقد تجاوزته.

كُتب هذا التحويل بلغة Ada، وبناءً على تصميم اللغة، فإنه يُطلق "خطأ في المعامل" (Operand Error) عند فيض الرقم العائم. كانت هناك سبعة متغيرات في الوحدة مرشحة للحماية ضد مثل هذه الأخطاء، لكن ثلاثة منها تُركت دون حماية بناءً على مبرر صريح بأن التحليل أظهر أن القيم لا يمكن أن تتجاوز الحدود الآمنة؛ وهو تحليل أُجري خصيصاً لـ "أريان 4". وكان متغير الانحياز الأفقي أحد هذه الثلاثة. وعندما انطلق الاستثناء، قام معالج الأخطاء بتفريغ الحالة الداخلية للنظام إلى ناقل البيانات وأوقف المعالج. أما نظام المرجع العطالي الاحتياطي، الذي كان يشغل الكود نفسه بمدخلات متطابقة، فقد توقف بالطريقة نفسها قبل بضع دورات. قرأ كمبيوتر المتن تفريغ التشخيص وكأنه بيانات وضعية الصاروخ، وما تبع ذلك في سلسلة التحكم كان نتيجة حتمية.

والأسوأ من ذلك، أن روتين المحاذاة لم يكن له أي داعٍ للاستمرار في العمل أصلاً. فقد وجد فقط للتعامل مع حالة طوارئ في العد التنازلي لـ "أريان 4"، حيث قد يتطلب التوقف المتأخر إعادة محاذاة المنصة العطالية دون إعادة بدء التسلسل من أوله. ولم تكن إجراءات العد التنازلي في "أريان 5" تتضمن مثل هذه الحالة، وظل الكود نشطاً أثناء الطيران ببساطة لأن أحداً لم يقم بإزالته.

ما غاب عن المراجعة

كان تقرير "ليونز" صارماً في توضيح سبب عدم اكتشاف أي من هذا مسبقاً. فقد جرت إجازة نظام المرجع العطالي بشكل منفصل وفقاً لمواصفات لم تتضمن مسار طيران "أريان 5". كما اختُبرت برمجيات الطيران كاملة في محاكاة حلقة مغلقة، ولكن استُبدل نظام المرجع العطالي الفعلي بمحاكٍ بحجة أن سلوك الوحدة الحقيقية معروف مسبقاً. ولم تُمرر قيم الطيران الفعلية لمتغير الانحياز الأفقي عبر كود التحويل الحقيقي على الأرض قط؛ فكان اللقاء الأول للقاذف مع مسار طيرانه الخاص هو لحظة الإطلاق.

ثمة إغراء عند قراءة هذا بتصنيف الكارثة تحت بند "فيض العدد الصحيح" والمضي قدماً. لكن الدرس الأعمق الذي استخلصته اللجنة كان يتعلق بـ "إعادة الاستخدام". فقد فُرض أن المكونات التي جرت إجازتها لمركبة ما هي مجازة بالضرورة لمركبة أخرى طالما أن الواجهات متطابقة. كان افتراضاً معقولاً، لكنه كان خاطئاً أيضاً، وكل فرد في سلسلة المراجعين الذين كان بإمكانهم التشكيك فيه كان يملك سبباً وجيهاً لعدم القيام بذلك.

ما نجهله حتى الآن

نحن نعرف ماهية الخطأ البرمجي، لكن ما لا يتضح تماماً هو لماذا كان قاذف في عام 1996 لا يزال يشغل مسارات برمجية وجدت فقط لخدمة إجراءات عد تنازلي من الثمانينيات. إن الوثائق الخاصة بتطوير نظام المرجع العطالي الأصلي لـ "أريان 4" شحيحة، وبعض الأشخاص الذين اتخذوا قرارات التصميم الأصلية كانوا قد تقاعدوا.

ولا نعرف، بأي وسيلة كمية، مدى تكرار هذا النمط في إلكترونيات الطيران المجازة اليوم. لقد أنتجت الإصلاحات التي تلت "أريان 5" في وكالة الفضاء الأوروبية معيار تطوير أكثر نقاءً هو ECSS، لكن المشكلة الأساسية — المكونات المعاد استخدامها والتي تحمل افتراضات ضمنية حول المركبة المضيفة — هي مسألة ثقافة بقدر ما هي مسألة إجراءات، والثقافة يصعب تدقيقها.

ولا نعرف عدد الحوادث الوشيكة التي استُوعبت بصمت منذ ذلك الحين. ففشل الإطلاق أمر مرئي للعيان، أما العدد الصحيح الذي تصادف دخوله في النطاق المطلوب لأن مسار الرحلة كان أقل انحداراً بكسر بسيط، فليس كذلك.

أعيد بناء الأقمار الأربعة لبعثة "كلوستر" من قطع الغيار وأُطلقت على متن صواريخ "سويوز" في عام 2000، وعملت في تشكيلها المخطط لأكثر من عشرين عاماً. أما برمجيات الطيران للإطلاق التالي لـ "أريان 5"، فقد أزالت روتين المحاذاة بالكامل.

Em 4 de junho de 1996, o novo lançador pesado da Europa ultrapassou a canopia da selva em Kourou, voou por trinta e sete segundos e despedaçou-se. A causa foi uma linha de código Ada escrita para um foguete diferente uma década antes.

O Ariane 5 repousava na plataforma ELA-3 no Centre Spatial Guyanais, na Guiana Francesa, abastecido e em contagem decrescente pela primeira vez. A bordo seguiam quatro satélites idênticos para a Cluster mission, um programa da Agência Espacial Europeia para estudar a interação do vento solar com a magnetosfera da Terra. Cada um era o produto de cerca de uma década de trabalho. O próprio lançador tinha custado à agência cerca de sete bilhões de dólares e dez anos de desenvolvimento. A descolagem ocorreu às 12:34 UTC. O foguetão subiu de forma limpa, inclinou-se para o rumo planeado e, durante trinta e seis segundos, fez exatamente o que era suposto fazer.

Aos T+36,7 segundos, ao atingir uma velocidade horizontal superior a tudo o que o antigo Ariane 4 alguma vez vira naquele ponto do voo, o sistema de referência inercial ativo a bordo detetou o que interpretou como uma falha interna catastrófica e desligou-se. O controle passou para a unidade de reserva, que já falhara pelo mesmo motivo setenta e dois milissegundos antes. Sem dados de navegação, o computador de bordo interpretou padrões de bits de diagnóstico do sistema inercial inativo como dados de voo e ordenou a deflexão total das tubeiras do motor. O foguetão inclinou-se bruscamente, as cargas aerodinâmicas arrancaram os propulsores do estágio central e o sistema de segurança do polígono acionou a autodestruição aos T+39 segundos. Cerca de meio bilhão de dólares em hardware choveram sobre o manguezal.

Uma conversão de sete linhas

A Lions Commission, presidida pelo matemático francês Jacques-Louis Lions, apresentou o seu relatório seis semanas depois. O documento é uma das análises forenses mais nítidas da engenharia de software. A falha residia no Sistema de Referência Inercial, o SRI, cujo software fora herdado integralmente do Ariane 4. No interior do SRI, uma rotina medira o desvio horizontal do foguetão — um valor útil apenas antes da descolagem, para alinhar a plataforma. Esta convertia um número de vírgula flutuante de 64 bits que representava esse desvio num inteiro assinado de 16 bits. No Ariane 4, as velocidades horizontais atingidas durante a janela de alinhamento nunca excederam o teto de 32.767 de um inteiro assinado de 16 bits. No Ariane 5, com uma trajetória mais íngreme e veloz, isso aconteceu.

A conversão fora escrita em Ada e, pelo design da linguagem, gerava um Erro de Operando quando o valor flutuante transbordava. Sete variáveis no módulo eram candidatas a proteção contra tais erros. Três foram deixadas desprotegidas sob o fundamento explícito de que as análises tinham demonstrado que os valores nunca poderiam exceder os limites de segurança — análises essas realizadas para o Ariane 4. A variável de desvio horizontal era uma das três. Quando a exceção foi disparada, o manipulador despejou o estado interno do SRI no barramento de dados e parou o processador. O SRI de reserva, executando o mesmo código com as mesmas entradas, parara da mesma forma alguns ciclos antes. O computador de bordo leu o despejo de diagnóstico como se fossem dados de atitude. Tudo o que se seguiu foi inevitável.

Pior ainda: a rotina de alinhamento não tinha qualquer razão para estar a ser executada. Ela existia apenas para lidar com uma contingência na contagem decrescente do Ariane 4, onde uma interrupção tardia poderia exigir o realinhamento da plataforma inercial sem reiniciar a sequência. O procedimento de contagem do Ariane 5 não previa tal contingência. O código estava ativo durante o voo puramente porque ninguém o removera.

O que a revisão deixou passar

O relatório Lions é implacável quanto ao motivo pelo qual nada disto foi detetado. O SRI fora qualificado isoladamente face a uma especificação que não incluía a trajetória do Ariane 5. Todo o software de voo fora testado numa simulação de circuito fechado, mas o próprio SRI foi substituído por um simulador em vez da unidade real, sob o argumento de que o comportamento da unidade real já era conhecido. Os valores reais de voo da variável de desvio horizontal nunca foram processados pelo código de conversão real em terra. O primeiro encontro do lançador com a sua própria trajetória foi o lançamento.

Ao ler isto, há a tentação de classificar o desastre como um simples "transbordo de inteiros" e seguir em frente. A lição mais profunda que a comissão retirou dizia respeito à reutilização. Assumiu-se que os componentes qualificados para um veículo estariam qualificados para outro porque as interfaces coincidiam. A suposição era razoável. No entanto, estava errada, e a cadeia de revisores que poderia tê-la questionado tinha, cada um, um motivo defensável para não o fazer.

O que ainda não sabemos

Sabemos qual era o erro. O que é menos claro é por que razão um lançador de 1996 ainda executava caminhos de código que existiam apenas para servir um procedimento de contagem decrescente da década de 1980. A documentação do desenvolvimento original do SRI do Ariane 4 é escassa, e algumas das pessoas que tomaram as decisões de design originais já se tinham reformado.

Não sabemos, de forma quantificada, com que frequência este padrão se repete na aviónica qualificada para voo atualmente. As reformas na ESA após o Ariane 5 produziram um padrão de desenvolvimento mais rigoroso, o ECSS, mas o problema subjacente — componentes reutilizados que carregam suposições implícitas sobre o seu veículo hospedeiro — é uma questão de cultura tanto quanto de processo, e a cultura é difícil de auditar.

E não sabemos quantos incidentes evitados por pouco foram silenciosamente absorvidos desde então. Falhas de lançamento são visíveis. Um inteiro convertido que por acaso coube no espaço de memória porque a trajetória foi uma fração menos acentuada, não o é.

Os quatro satélites Cluster foram reconstruídos a partir de peças sobresselentes e lançados em foguetões Soyuz no ano 2000. Funcionaram, em formação, durante mais de vinte anos. O software de voo para o lançamento seguinte do Ariane 5 removeu a rotina de alinhamento por completo.

4 जून 1996 को, यूरोप के नए हैवी-लिफ्ट रॉकेट ने कुरू में जंगलों की छतरी को पार किया, सैंतीस सेकंड तक उड़ान भरी और फिर स्वयं को छिन्न-भिन्न कर लिया। इसकी वजह एडा कोड की एक पंक्ति थी, जिसे एक दशक पहले किसी और रॉकेट के लिए लिखा गया था।

फ्रेंच गयाना के Centre Spatial Guyanais में स्थित पैड ELA-3 पर आरियान 5 खड़ा था, ईंधन से भरा हुआ और अपनी पहली उड़ान की उल्टी गिनती गिनता हुआ। इसके भीतर Cluster mission के लिए चार एक समान उपग्रह रखे थे—यह यूरोपीय अंतरिक्ष एजेंसी का एक कार्यक्रम था जिसका उद्देश्य यह अध्ययन करना था कि सौर पवन पृथ्वी के चुंबकमंडल के साथ कैसे परस्पर क्रिया करती है। प्रत्येक उपग्रह लगभग एक दशक की मेहनत का परिणाम था। स्वयं इस प्रक्षेपक (launcher) के विकास पर एजेंसी के लगभग सात बिलियन डॉलर और दस साल खर्च हुए थे। प्रक्षेपण UTC समयानुसार 12:34 बजे हुआ। रॉकेट ने स्पष्ट उड़ान भरी, अपने निर्धारित मार्ग की ओर मुड़ा और छत्तीस सेकंड तक बिल्कुल वैसा ही प्रदर्शन किया जैसा उससे अपेक्षित था।

उड़ान के 36.7 सेकंड बीतने पर, जब रॉकेट उस क्षैतिज वेग से गुजर रहा था जिसे पुराने Ariane 4 ने अपनी उड़ान के उस बिंदु पर कभी नहीं देखा था, तब बोर्ड पर सक्रिय जड़त्वीय संदर्भ प्रणाली (active inertial reference system) ने एक ऐसी त्रुटि पकड़ी जिसे उसने एक विनाशकारी आंतरिक खराबी समझ लिया और खुद को बंद कर लिया। नियंत्रण बैकअप यूनिट के पास चला गया, जो ठीक 72 मिलीसेकंड पहले इसी कारण से विफल हो चुकी थी। नेविगेशन डेटा के अभाव में, ऑन-बोर्ड कंप्यूटर ने मृत जड़त्वीय प्रणाली से मिलने वाले डायग्नोस्टिक बिट पैटर्न को उड़ान का डेटा समझ लिया और इंजन नोजल को पूरी तरह झुकने का निर्देश दे दिया। रॉकेट तेजी से एक ओर झुक गया, वायुगतिकीय भार (aerodynamic loads) ने बूस्टरों को मुख्य स्टेज से अलग कर दिया, और रेंज सुरक्षा प्रणाली ने उड़ान के 39वें सेकंड पर आत्म-विनाश को सक्रिय कर दिया। लगभग आधा बिलियन डॉलर के उपकरण मैंग्रोव दलदल में मलबे के रूप में बरस पड़े।

सात पंक्तियों का एक रूपांतरण

फ्रांसीसी गणितज्ञ जैक-लुई लायंस की अध्यक्षता वाले Lions Commission ने छह सप्ताह बाद अपनी रिपोर्ट दी। यह रिपोर्ट सॉफ्टवेयर इंजीनियरिंग के क्षेत्र में सबसे स्पष्ट फॉरेंसिक दस्तावेजों में से एक है। दोष जड़त्वीय संदर्भ प्रणाली यानी SRI में था, जिसका सॉफ्टवेयर पूरी तरह से आरियान 4 से विरासत में मिला था। SRI के भीतर, एक रूटीन रॉकेट के हॉरिजॉन्टल बायस (क्षैतिज झुकाव) को मापता था—यह मान केवल प्रक्षेपण से पहले प्लेटफॉर्म को संरेखित करने के लिए उपयोगी था। इसने उस झुकाव को दर्शाने वाली एक 64-बिट फ्लोटिंग-पॉइंट संख्या को 16-बिट साइन्ड इंटीजर में बदल दिया। आरियान 4 पर, संरेखण की अवधि के दौरान क्षैतिज वेग कभी भी 16-बिट साइन्ड इंटीजर की 32,767 वाली सीमा से ऊपर नहीं गया था। लेकिन आरियान 5 के अधिक तीव्र और तेज़ प्रक्षेपवक्र में, वह सीमा पार हो गई।

यह रूपांतरण Ada में लिखा गया था और अपनी भाषाई संरचना के कारण, फ्लोट के ओवरफ्लो होने पर इसमें 'ऑपरेंड एरर' (Operand Error) उत्पन्न हुआ। मॉड्यूल के सात चर (variables) इस तरह की त्रुटियों से सुरक्षा के पात्र थे। उनमें से तीन को इस स्पष्ट आधार पर असुरक्षित छोड़ दिया गया था कि विश्लेषण से पता चला था कि उनके मान कभी भी सुरक्षित सीमा से बाहर नहीं जाएंगे—और यह विश्लेषण आरियान 4 के लिए किया गया था। हॉरिजॉन्टल-बायस चर उन्हीं तीन में से एक था। जब यह एक्सेप्शन ट्रिगर हुआ, तो हैंडलर ने SRI की आंतरिक स्थिति को डेटा बस पर डंप कर दिया और प्रोसेसर को रोक दिया। बैकअप SRI ने भी, जो समान इनपुट पर समान कोड चला रहा था, कुछ ही पलों पहले इसी तरह काम करना बंद कर दिया था। ऑन-बोर्ड कंप्यूटर ने उस डायग्नोस्टिक डंप को ऐसे पढ़ा जैसे कि वह एटीट्यूड डेटा हो। इसके बाद की सारी तबाही अपरिहार्य थी।

इससे भी बुरा यह था कि उस संरेखण रूटीन के चलते रहने का कोई तुक ही नहीं था। वह केवल आरियान 4 की उल्टी गिनती में आने वाली एक संभावित बाधा से निपटने के लिए बनाया गया था, जहाँ अंतिम क्षणों की देरी के कारण अनुक्रम को फिर से शुरू किए बिना जड़त्वीय प्लेटफॉर्म को फिर से संरेखित करने की आवश्यकता पड़ सकती थी। आरियान 5 की काउंटडाउन प्रक्रिया में ऐसी कोई संभावना ही नहीं थी। वह कोड उड़ान के दौरान केवल इसलिए सक्रिय था क्योंकि किसी ने उसे हटाना जरूरी नहीं समझा था।

समीक्षा में क्या छूट गया

लायंस की रिपोर्ट इस बात को लेकर बेहद सख्त है कि आखिर यह सब पकड़ में क्यों नहीं आया। SRI को एक ऐसी विशिष्टता (specification) के आधार पर अलग से प्रमाणित किया गया था जिसमें आरियान 5 का प्रक्षेपवक्र शामिल ही नहीं था। पूरे उड़ान सॉफ्टवेयर का परीक्षण क्लोज्ड-लूप सिमुलेशन में किया गया था, लेकिन SRI की जगह एक सिमुलेटर का उपयोग किया गया था, क्योंकि यह माना गया था कि असली इकाई का व्यवहार पहले से ही ज्ञात है। हॉरिजॉन्टल-बायस चर के वास्तविक उड़ान मानों को जमीन पर कभी भी वास्तविक रूपांतरण कोड के माध्यम से जांचा ही नहीं गया। प्रक्षेपक का अपने स्वयं के प्रक्षेपवक्र से पहला सामना ही उसका प्रक्षेपण था।

इसे पढ़कर मन में यह लालच आता है कि इस आपदा को केवल "इंटीजर ओवरफ्लो" की श्रेणी में डाल दिया जाए और आगे बढ़ा जाए। लेकिन कमीशन ने जो गहरा सबक निकाला, वह 'पुन: उपयोग' (reuse) के बारे में था। एक वाहन के लिए योग्य ठहराए गए घटकों को दूसरे के लिए भी योग्य मान लिया गया क्योंकि उनके इंटरफेस मेल खाते थे। यह धारणा तर्कसंगत थी। लेकिन यह गलत भी थी, और उन समीक्षकों की श्रृंखला, जो इस पर सवाल उठा सकते थे, उनमें से प्रत्येक के पास ऐसा न करने का एक उचित कारण था।

वह जो हम अब भी नहीं जानते

हम जानते हैं कि बग क्या था। जो बात कम स्पष्ट है वह यह है कि 1996 का एक प्रक्षेपक अभी भी उन कोड मार्गों (code paths) को क्यों चला रहा था जो केवल 1980 के दशक की काउंटडाउन प्रक्रिया के लिए बनाए गए थे। मूल आरियान 4 SRI विकास के दस्तावेज़ बहुत कम हैं, और मूल डिजाइन के निर्णय लेने वाले कुछ लोग सेवानिवृत्त हो चुके थे।

हम किसी भी मात्रात्मक तरीके से यह नहीं जानते कि आज उड़ान-योग्य एवियोनिक्स में यह पैटर्न कितनी बार दोहराया जाता है। ESA में आरियान 5 के बाद के सुधारों ने एक बेहतर विकास मानक, ECSS, को जन्म दिया, लेकिन अंतर्निहित समस्या—पुन: उपयोग किए गए घटक जिनमें उनके मेजबान वाहन के बारे में अंतर्निहित धारणाएं छिपी होती हैं—प्रक्रिया के साथ-साथ संस्कृति का भी सवाल है, और संस्कृति का ऑडिट करना कठिन है।

और हम यह भी नहीं जानते कि तब से लेकर अब तक कितनी ऐसी विफलताएं हैं जिन्हें चुपचाप आत्मसात कर लिया गया। प्रक्षेपण की विफलताएं तो दिखाई देती हैं। लेकिन एक रूपांतरित पूर्णांक जो सिर्फ इसलिए फिट बैठ गया क्योंकि प्रक्षेपवक्र थोड़ा कम तीव्र था, वह दिखाई नहीं देता।

चारों क्लस्टर उपग्रहों को अतिरिक्त पुर्जों से फिर से बनाया गया और 2000 में सोयुज रॉकेटों के जरिए प्रक्षेपित किया गया। उन्होंने बीस से अधिक वर्षों तक एक साथ मिलकर काम किया। आरियान 5 के अगले प्रक्षेपण के उड़ान सॉफ्टवेयर से उस संरेखण रूटीन को पूरी तरह से हटा दिया गया था।

Pada 4 Juni 1996, roket pengangkut berat terbaru Eropa melesat melampaui kanopi hutan di Kourou, terbang selama tiga puluh tujuh detik, lalu hancur berkeping-keping. Musababnya adalah sebaris kode Ada yang ditulis untuk roket lain satu dekade sebelumnya.

Ariane 5 berdiri di landasan ELA-3 di Centre Spatial Guyanais di Guyana Prancis, sudah terisi bahan bakar dan menghitung mundur untuk pertama kalinya. Di dalamnya terdapat empat satelit identik untuk Cluster mission, sebuah program Badan Antariksa Eropa untuk mempelajari bagaimana angin surya berinteraksi dengan magnetosfer Bumi. Masing-masing merupakan hasil kerja selama kurang lebih sepuluh tahun. Roket peluncur itu sendiri telah menelan biaya sekitar tujuh miliar dolar dan sepuluh tahun pengembangan bagi badan tersebut. Peluncuran terjadi pada pukul 12:34 UTC. Roket tersebut mendaki dengan mulus, berputar menuju arah yang telah direncanakan, dan selama tiga puluh enam detik, ia melakukan tepat apa yang seharusnya dilakukan.

Pada T+36,7 detik, saat melewati kecepatan horizontal yang lebih tinggi daripada yang pernah dialami Ariane 4 sebelumnya pada titik penerbangan tersebut, sistem referensi inersia aktif di dalamnya mendeteksi apa yang ia anggap sebagai kerusakan internal yang fatal dan mematikan dirinya sendiri. Kendali dialihkan ke unit cadangan, yang ternyata telah gagal karena alasan yang sama tujuh puluh dua milidetik sebelumnya. Tanpa data navigasi, komputer di dalam roket menafsirkan pola bit diagnostik dari sistem inersia yang mati sebagai data penerbangan dan memerintahkan nosel mesin untuk berbelok penuh. Roket tersebut menukik tajam, beban aerodinamis merobek pendorong dari tahap inti, dan sistem keamanan jangkauan memicu penghancuran diri pada T+39 detik. Sekitar setengah miliar dolar perangkat keras jatuh menghujani rawa bakau.

Konversi tujuh baris

Lions Commission, yang dipimpin oleh matematikawan Prancis Jacques-Louis Lions, merilis laporannya enam minggu kemudian. Laporan tersebut merupakan salah satu dokumen forensik paling gamblang dalam rekayasa perangkat lunak. Kesalahannya terletak pada Sistem Referensi Inersia, SRI, yang perangkat lunaknya diwarisi sepenuhnya dari Ariane 4. Di dalam SRI, sebuah rutin mengukur bias horizontal roket—sebuah nilai yang hanya berguna sebelum lepas landas, untuk menyejajarkan platform. Rutin ini mengonversi angka titik-mengambang 64-bit yang mewakili bias tersebut menjadi bilangan bulat bertanda 16-bit. Pada Ariane 4, kecepatan horizontal yang dicapai selama jendela penjajaran tidak pernah melampaui batas atas 32.767 dari bilangan bulat bertanda 16-bit. Pada Ariane 5, dengan lintasan yang lebih curam dan lebih cepat, kecepatan tersebut melampauinya.

Konversi tersebut ditulis dalam Ada dan, berdasarkan desain bahasanya, memunculkan Operand Error ketika angka titik-mengambang tersebut meluap. Tujuh variabel dalam modul itu merupakan kandidat untuk dilindungi dari kesalahan semacam itu. Tiga variabel dibiarkan tanpa perlindungan dengan alasan eksplisit bahwa analisis telah menunjukkan bahwa nilainya tidak akan pernah melampaui batas aman—analisis yang dilakukan untuk Ariane 4. Variabel bias-horizontal adalah salah satu dari ketiganya. Ketika eksepsi muncul, penangan membuang status internal SRI ke bus data dan menghentikan prosesor. SRI cadangan, yang menjalankan kode yang sama pada input yang sama, telah berhenti dengan cara yang sama beberapa siklus sebelumnya. Komputer di dalam roket membaca buangan diagnostik tersebut seolah-olah itu adalah data sikap. Segala sesuatu yang terjadi setelahnya mengikuti secara tak terelakkan.

Lebih buruk lagi: rutin penjajaran tersebut sebenarnya tidak perlu lagi dijalankan. Ia ada hanya untuk menangani kemungkinan buruk dalam hitung mundur Ariane 4, di mana penundaan di saat-akhir terakhir mungkin mengharuskan platform inersia untuk melakukan penjajaran ulang tanpa memulai kembali urutannya. Prosedur hitung mundur Ariane 5 tidak memiliki kemungkinan seperti itu. Kode tersebut tetap aktif selama penerbangan murni karena tidak ada yang menghapusnya.

Apa yang terlewatkan oleh peninjauan

Laporan Lions tidak mengenal ampun tentang mengapa semua ini tidak terdeteksi. SRI telah dikualifikasi secara terisolasi terhadap spesifikasi yang tidak menyertakan lintasan Ariane 5. Perangkat lunak penerbangan lengkap telah diuji dalam simulasi lup-tertutup, tetapi SRI itu sendiri digantikan dengan simulator alih-alih unit asli, dengan alasan bahwa perilaku unit aslinya sudah diketahui. Nilai penerbangan aktual dari variabel bias-horizontal tidak pernah dimasukkan melalui kode konversi asli di darat. Pertemuan pertama roket peluncur tersebut dengan lintasannya sendiri adalah saat peluncuran itu sendiri.

Ada godaan, saat membaca ini, untuk menggolongkan bencana ini di bawah "integer overflow" dan mengabaikannya. Pelajaran lebih mendalam yang ditarik oleh komisi tersebut adalah tentang penggunaan kembali. Komponen yang dikualifikasi untuk satu kendaraan dianggap terkualifikasi untuk kendaraan lain karena antarmukanya cocok. Asumsi itu masuk akal. Namun, asumsi itu juga salah, dan rantai peninjau yang seharusnya bisa mempertanyakannya masing-masing memiliki alasan yang dapat dipertahankan untuk tidak melakukannya.

Apa yang masih belum kita ketahui

Kita tahu apa kutu tersebut. Yang kurang jelas adalah mengapa roket peluncur tahun 1996 masih menjalankan jalur kode yang ada hanya untuk melayani prosedur hitung mundur tahun 1980-an. Dokumentasi dari pengembangan asli SRI Ariane 4 sangat minim, dan beberapa orang yang membuat keputusan desain awal telah pensiun.

Kita tidak tahu, secara kuantitatif, seberapa sering pola ini berulang dalam avionik terkualifikasi-terbang saat ini. Reformasi pasca-Ariane-5 di ESA menghasilkan standar pengembangan yang lebih bersih, ECSS, tetapi masalah yang mendasarinya—komponen yang digunakan kembali yang membawa asumsi implisit tentang kendaraan inangnya—adalah masalah budaya sekaligus proses, dan budaya sulit untuk diaudit.

Dan kita tidak tahu berapa banyak kejadian hampir celaka yang telah diserap secara diam-diam sejak saat itu. Kegagalan peluncuran terlihat jelas. Bilangan bulat terkonversi yang kebetulan pas karena lintasannya sedikit lebih dangkal tidaklah terlihat.

Keempat satelit Cluster dibangun kembali dari suku cadang dan diluncurkan dengan roket Soyuz pada tahun 2000. Satelit-satelit tersebut bekerja, dalam formasi, selama lebih dari dua puluh tahun. Perangkat lunak penerbangan untuk peluncuran Ariane 5 berikutnya menghapus rutin penjajaran tersebut sepenuhnya.

Le 4 juin 1996, le nouveau lanceur lourd européen franchit la canopée de Kourou, vola trente-sept secondes, et se désintégra. La cause : une ligne de code Ada écrite pour une autre fusée une décennie plus tôt.

L’Ariane 5 trônait sur le pas de tir ELA-3 au Centre Spatial Guyanais en Guyane française, réservoirs pleins, décomptant pour la première fois. À son bord se trouvaient quatre satellites identiques pour la Cluster mission, un programme de l’Agence spatiale européenne visant à étudier l’interaction du vent solaire avec la magnétosphère terrestre. Chacun représentait environ une décennie de travail. Le lanceur lui-même avait coûté à l’agence quelque sept milliards de dollars et dix ans de développement. Le décollage eut lieu à 12h34 UTC. La fusée s’éleva sans encombre, s’orienta selon le cap prévu et, pendant trente-six secondes, fit exactement ce qu’on attendait d’elle.

À T+36,7 secondes, alors qu’elle atteignait une vitesse horizontale supérieure à tout ce que l’ancienne Ariane 4 n’avait jamais connu à ce stade du vol, le système de référence inertielle actif à bord détecta ce qu’il interpréta comme une défaillance interne catastrophique et s’arrêta. Le contrôle passa à l’unité de secours, qui avait déjà échoué pour la même raison soixante-douze millisecondes plus tôt. Privé de données de navigation, l’ordinateur de bord interpréta les séquences binaires de diagnostic du système inertiel défaillant comme des données de vol et ordonna l’inclinaison maximale des tuyères. La fusée vira brutalement, les charges aérodynamiques arrachèrent les boosters de l’étage principal, et le système de sauvegarde déclencha l’autodestruction à T+39 secondes. Environ un demi-milliard de dollars de matériel s’abattit en pluie sur la mangrove.

Une conversion de sept lignes

La Lions Commission, présidée par le mathématicien français Jacques-Louis Lions, rendit son rapport six semaines plus tard. Ce document reste l’une des analyses techniques les plus limpides de l’ingénierie logicielle. La faille résidait dans le Système de Référence Inertielle, le SRI, dont le logiciel avait été intégralement hérité d’Ariane 4. Au sein du SRI, une routine mesurait le biais horizontal de la fusée — une valeur utile uniquement avant le décollage pour aligner la plateforme. Elle convertissait un nombre à virgule flottante de 64 bits représentant ce biais en un entier signé de 16 bits. Sur Ariane 4, les vitesses horizontales atteintes durant la fenêtre d’alignement ne dépassaient jamais le plafond de 32 767 d’un entier signé de 16 bits. Sur Ariane 5, avec sa trajectoire plus abrupte et plus rapide, ce fut le cas.

La conversion était écrite en Ada et, de par la conception du langage, générait une Erreur d’Opérande lorsque le flottant débordait. Sept variables du module étaient susceptibles d’être protégées contre de telles erreurs. Trois furent laissées sans protection au motif explicite qu’une analyse avait démontré que les valeurs ne pourraient jamais dépasser les limites de sécurité — une analyse réalisée pour Ariane 4. La variable du biais horizontal était l’une de ces trois. Lorsque l’exception se déclencha, le gestionnaire d’erreurs transféra l’état interne du SRI sur le bus de données et arrêta le processeur. Le SRI de secours, exécutant un code identique sur des entrées identiques, s’était arrêté de la même manière quelques cycles plus tôt. L’ordinateur de bord lut ce vidage de diagnostic comme s’il s’agissait de données d’attitude. Tout ce qui suivit en découla inévitablement.

Pire encore : la routine d’alignement n’avait aucune raison d’être encore active. Elle n’existait que pour parer à une éventualité du compte à rebours d’Ariane 4, où une interruption tardive pourrait nécessiter un réalignement de la plateforme inertielle sans redémarrer la séquence. La procédure de lancement d’Ariane 5 ne prévoyait pas une telle éventualité. Le code était actif durant le vol pour la simple raison que personne ne l’avait retiré.

Ce que l’examen a omis

Le rapport Lions est sans concession sur les raisons pour lesquelles rien de tout cela n’avait été détecté. Le SRI avait été qualifié isolément par rapport à une spécification qui n’incluait pas la trajectoire d’Ariane 5. Le logiciel de vol complet avait été testé en simulation en boucle fermée, mais le SRI lui-même avait été remplacé par un simulateur plutôt que par l’unité réelle, au motif que le comportement de cette dernière était déjà connu. Les valeurs de vol réelles de la variable de biais horizontal ne furent jamais soumises au véritable code de conversion au sol. Le premier contact du lanceur avec sa propre trajectoire fut le lancement lui-même.

On est tenté, à la lecture de ce récit, de classer la catastrophe au rayon des « dépassements de capacité » et de passer à autre chose. La leçon plus profonde que la commission en a tirée concernait la réutilisation. On a supposé que des composants qualifiés pour un véhicule l’étaient pour un autre parce que les interfaces correspondaient. L’hypothèse était raisonnable. Elle était également erronée, et chacun des réviseurs de la chaîne qui aurait pu la remettre en question avait une raison défendable de ne pas le faire.

Ce que nous ignorons encore

Nous savons en quoi consistait le bug. Ce qui est moins clair, c’est pourquoi un lanceur de 1996 exécutait encore des chemins de code nés uniquement pour servir une procédure de compte à rebours des années 1980. La documentation issue du développement initial du SRI d’Ariane 4 est succincte, et certains des responsables des décisions de conception originelles étaient partis à la retraite.

Nous ignorons, de manière quantifiée, à quelle fréquence ce schéma se répète aujourd’hui dans l’avionique qualifiée pour le vol. Les réformes post-Ariane 5 à l’ESA ont produit une norme de développement plus rigoureuse, l’ECSS, mais le problème de fond — des composants réutilisés porteurs d’hypothèses implicites sur leur véhicule hôte — est une question de culture autant que de processus, et la culture est difficile à auditer.

Et nous ignorons combien de quasi-accidents ont été discrètement absorbés depuis lors. Les échecs au lancement sont visibles. Un entier converti qui finit par loger dans son espace parce que la trajectoire était un tantinet moins raide ne l’est pas.

Les quatre satellites Cluster furent reconstruits à partir de pièces de rechange et lancés par des fusées Soyouz en 2000. Ils fonctionnèrent en formation pendant plus de vingt ans. Le logiciel de vol du lancement suivant d’Ariane 5 supprima purement et simplement la routine d’alignement.

1996年6月4日、欧州の新型大型ロケットはクールーの密林を抜け、37秒間の飛行を経て自壊した。原因は10年前、別のロケットのために書かれた一行のAdaコードにあった。

アリアン5は、フランス領ギアナのCentre Spatial GuyanaisにあるELA-3発射台に据え置かれ、燃料を充填され、初めてのカウントダウンを進めていた。機体に搭載されていたのは、欧州宇宙機関（ESA）のCluster missionのための4機の同一仕様の衛星である。これは、太陽風が地球の磁気圏とどのように相互作用するかを研究するプログラムだった。各衛星は約10年に及ぶ歳月の結晶であり、打ち上げ機自体も、同機関が約70億ドルの費用と10年の開発期間を投じて作り上げたものだった。離陸はUTC 12:34。ロケットは滑らかに上昇し、予定の針路へとロールを開始した。そして36秒間、まさに設計通りの飛行を続けた。

T+36.7秒、それまでの飛行段階で旧型のAriane 4が経験したことのないほどの水平速度に達したその時、搭載されていた稼働中の慣性基準装置（IRS）が、壊滅的な内部故障と解釈される事象を検知し、システムを停止させた。制御はバックアップ・ユニットへと移されたが、そちらもわずか72ミリ秒前に同じ理由で既に故障していた。航法データを失ったオンボード・コンピュータは、停止した慣性システムから送られてきた診断用のビットパターンを飛行データと誤認し、エンジンノズルの向きを限界まで偏向させるよう命じた。ロケットは急激にピッチを変え、空気力学的負荷によってブースターがコアステージから引き剥がされた。T+39秒、射場安全システムが自爆装置を作動させた。約5億ドル相当のハードウェアが、マングローブの湿地帯へと降り注いだ。

7行の変換処理

フランスの数学者ジャック＝ルイ・リオンが委員長を務めたLions Commissionは、6週間後に報告書を提出した。この報告書は、ソフトウェア工学における最も明晰な鑑識文書の一つである。欠陥は、ソフトウェアをアリアン4からそのまま継承していた慣性基準装置SRIの中にあった。SRIの内部では、あるルーチンがロケットの水平バイアスを測定していた。これは、発射前にプラットフォームのアライメント（調整）を行うためだけに有用な数値である。このルーチンは、そのバイアスを表す64ビット浮動小数点数を16ビット符号付き整数に変換していた。アリアン4では、アライメント期間中に達する水平速度が16ビット符号付き整数の上限である32,767を超えることはなかった。しかし、より急峻で高速な軌道を描くアリアン5では、その上限を超えてしまったのである。

この変換処理はAdaで記述されており、言語の設計上、浮動小数点がオーバーフローした際には「オペランド誤差（Operand Error）」を発生させるようになっていた。モジュール内の7つの変数がこうしたエラーに対する保護の検討対象となっていたが、そのうち3つは、分析によって数値が安全な限界を超えることはあり得ないと示されたという明確な根拠に基づき、保護されないまま放置されていた。その分析は、アリアン4のために行われたものだった。水平バイアスの変数は、その保護されなかった3つのうちの一つだった。例外が発生した瞬間、ハンドラはSRIの内部状態をデータバスに吐き出し、プロセッサを停止させた。同一のコードを同一の入力で実行していたバックアップのSRIも、数サイクル前に同じように停止していた。オンボード・コンピュータはその診断用ダンプを、あたかも姿勢データであるかのように読み取った。その後のすべては、不可避な帰結であった。

さらに悪いことに、このアライメント用ルーチンは、そもそも飛行中に動作している必要はなかった。それはアリアン4のカウントダウンにおける不測の事態、すなわちカウントダウンが後半で中断された際に、シーケンスを最初からやり直すことなく慣性プラットフォームを再調整しなければならない状況に対処するためだけに存在していた。アリアン5のカウントダウン手順には、そのような状況設定はなかった。そのコードが飛行中もアクティブだったのは、単に誰もそれを取り除かなかったからに過ぎない。

審査が見落としたもの

リオン報告書は、なぜこれらが事前に察知されなかったのかについて容赦のない指摘をしている。SRIは、アリアン5の飛行軌道を含まない仕様書に基づいて、単体での認証を受けていた。飛行ソフトウェア全体のテストはクローズドループ・シミュレーションで行われていたが、SRIの実機は、その挙動は既に既知であるという理由でシミュレータに置き換えられていた。水平バイアス変数の実際の飛行中の数値が、地上で実機の変換コードに通されることは一度もなかった。打ち上げ機が自身の飛行軌道と初めて遭遇したのは、本番の打ち上げ時だったのである。

これを読むと、この惨事を「整数オーバーフロー」の一言で片付け、先へ進みたくなる誘惑に駆られる。しかし、委員会が導き出したより深い教訓は、再利用に関するものだった。インターフェースが一致しているという理由で、ある機体で認証されたコンポーネントは、別の機体でも認証済みであると見なされた。その仮定は合理的ではあったが、同時に誤りでもあった。そして、その仮定に疑問を呈することができたはずの審査官たちの連鎖は、それぞれが疑問を持たなかったことに対して弁解の余地がある理由を抱えていた。

我々が依然として知らないこと

バグが何であったかは分かっている。それほど判然としていないのは、なぜ1996年の打ち上げ機が、1980年代のカウントダウン手順のためだけに存在するコードパスを依然として走らせていたのか、という点である。元々のアリアン4のSRI開発に関する資料は乏しく、初期の設計決定を下した人々のうち何人かは既に引退していた。

今日の飛行認証済みアビオニクスにおいて、このパターンがどの程度の頻度で繰り返されているのか、我々は定量的に把握できていない。アリアン5の失敗を受けたESAの改革は、より洗練された開発標準であるECSSを生み出したが、根本的な問題――再利用されたコンポーネントが、搭載される機体に関する暗黙の前提を引き継いでしまうこと――は、プロセスと同じくらい文化の問題であり、文化を監査するのは困難である。

そして、それ以来どれほどの「ニアミス」が静かに吸収されてきたのかも、我々には分からない。打ち上げの失敗は誰の目にも明らかだ。しかし、軌道がほんのわずかに緩やかだったおかげで、たまたま収まった変換整数については、誰も気づくことはないのである。

4機のクラスター衛星は予備機から再建造され、2000年にソユーズロケットで打ち上げられた。それらは編隊を組み、20年以上にわたって任務を全うした。アリアン5の次の打ち上げに向けた飛行ソフトウェアからは、アライメント用ルーチンは完全に削除されていた。

Am 4. Juni 1996 ließ Europas neue Schwerlastrakete das Blätterdach des Dschungels von Kourou hinter sich, flog siebenunddreißig Sekunden lang und riss sich selbst in Stücke. Die Ursache war eine Zeile Ada-Code, die ein Jahrzehnt zuvor für eine andere Rakete geschrieben worden war.

Die Ariane 5 stand auf dem Startplatz ELA-3 im Centre Spatial Guyanais in Französisch-Guayana, betankt und zum ersten Mal im Countdown. An Bord befanden sich vier identische Satelliten für die Cluster mission, ein Programm der Europäischen Weltraumorganisation zur Untersuchung der Wechselwirkung zwischen dem Sonnenwind und der Magnetosphäre der Erde. Jeder einzelne war das Ergebnis von etwa einem Jahrzehnt Arbeit. Die Trägerrakete selbst hatte die Organisation rund sieben Milliarden Dollar und zehn Jahre Entwicklung gekostet. Der Start erfolgte um 12:34 Uhr UTC. Die Rakete stieg sauber auf, drehte auf den geplanten Kurs und tat sechsunddreißig Sekunden lang genau das, wofür sie gebaut worden war.

Bei T+36,7 Sekunden, während sie eine Horizontalgeschwindigkeit erreichte, die über allem lag, was die ältere Ariane 4 jemals zu diesem Flugzeitpunkt erreicht hatte, registrierte das aktive Trägheitsreferenzsystem an Bord einen Fehler, den es als katastrophalen internen Defekt interpretierte, und schaltete sich ab. Die Steuerung ging auf die Ersatzeinheit über, die bereits zweiundsiebzig Millisekunden zuvor aus demselben Grund ausgefallen war. Ohne Navigationsdaten interpretierte der Bordcomputer diagnostische Bitmuster des toten Trägheitssystems als Flugdaten und befahl den Triebwerksdüsen den vollen Ausschlag. Die Rakete neigte sich abrupt, aerodynamische Lasten rissen die Booster von der Hauptstufe, und das Flugsicherheitssystem löste bei T+39 Sekunden die Selbstzerstörung aus. Hardware im Wert von etwa einer halben Milliarde Dollar regnete in den Mangrovensumpf.

Eine Konvertierung in sieben Zeilen

Die Lions Commission unter dem Vorsitz des französischen Mathematikers Jacques-Louis Lions legte sechs Wochen später ihren Bericht vor. Das Dokument ist eine der präzisesten forensischen Analysen in der Geschichte der Softwaretechnik. Der Fehler lag im Trägheitsreferenzsystem, dem SRI, dessen Software vollständig von der Ariane 4 übernommen worden war. Innerhalb des SRI maß eine Routine die horizontale Abweichung der Rakete – ein Wert, der nur vor dem Start nützlich ist, um die Plattform auszurichten. Sie konvertierte eine 64-Bit-Gleitkommazahl, die diese Abweichung darstellte, in eine vorzeichenbehaftete 16-Bit-Ganzzahl. Bei der Ariane 4 überstiegen die während des Ausrichtungsfensters erreichten Horizontalgeschwindigkeiten nie die Obergrenze von 32.767 einer vorzeichenbehafteten 16-Bit-Ganzzahl. Bei der Ariane 5 mit ihrer steileren, schnelleren Flugbahn taten sie es.

Die Konvertierung war in Ada geschrieben und löste aufgrund des Sprachdesigns einen „Operand Error“ aus, sobald die Gleitkommazahl überlief. Sieben Variablen im Modul kamen für einen Schutz gegen solche Fehler infrage. Drei wurden mit der expliziten Begründung ungeschützt gelassen, dass Analysen gezeigt hätten, die Werte könnten niemals die Sicherheitsgrenzen überschreiten – Analysen, die für die Ariane 4 durchgeführt worden waren. Die Variable für die horizontale Abweichung war eine dieser drei. Als die Ausnahme ausgelöst wurde, übertrug der Handler den internen Zustand des SRI auf den Datenbus und hielt den Prozessor an. Das Ersatz-SRI, das identischen Code mit identischen Eingaben ausführte, war einige Zyklen zuvor auf dieselbe Weise stehengeblieben. Der Bordcomputer las den Diagnose-Dump, als handele es sich um Lagedaten. Alles Weitere folgte unweigerlich.

Schlimmer noch: Die Ausrichtungsroutine hätte gar nicht mehr laufen dürfen. Sie existierte nur, um einen Eventualfall im Countdown der Ariane 4 abzudecken, bei dem ein später Stopp eine Neuausrichtung der Trägheitsplattform erfordern könnte, ohne die Sequenz neu zu starten. Das Countdown-Verfahren der Ariane 5 sah einen solchen Fall nicht vor. Der Code war während des Fluges nur deshalb aktiv, weil ihn niemand entfernt hatte.

Was die Überprüfung übersah

Der Lions-Bericht ist schonungslos in der Analyse, warum nichts davon bemerkt wurde. Das SRI war isoliert gegen eine Spezifikation qualifiziert worden, die die Flugbahn der Ariane 5 nicht enthielt. Die gesamte Flugsoftware war in einer Simulation mit geschlossenem Regelkreis getestet worden, doch das SRI selbst wurde durch einen Simulator anstatt durch das reale Gerät ersetzt, mit der Begründung, das Verhalten des realen Geräts sei bereits bekannt. Die tatsächlichen Flugwerte der Variable für die horizontale Abweichung wurden am Boden niemals durch den echten Konvertierungscode geschleust. Die erste Begegnung der Trägerrakete mit ihrer eigenen Flugbahn war der Start.

Es ist verlockend, beim Lesen dieses Berichts die Katastrophe unter „Integer-Überlauf“ abzuhaken und zur Tagesordnung überzugehen. Die tiefere Lehre, welche die Kommission zog, betraf jedoch die Wiederverwendung. Man ging davon aus, dass Komponenten, die für ein Fahrzeug qualifiziert waren, auch für ein anderes qualifiziert seien, solange die Schnittstellen übereinstimmten. Die Annahme war vernünftig. Sie war jedoch falsch, und die Kette von Prüfern, die sie hätten hinterfragen können, hatte jeweils vertretbare Gründe, es nicht zu tun.

Was wir noch immer nicht wissen

Wir wissen, was der Fehler war. Weniger klar ist, warum eine Trägerrakete von 1996 noch Codepfade abflog, die nur dazu dienten, ein Countdown-Verfahren aus den 1980er Jahren zu unterstützen. Die Dokumentation aus der ursprünglichen Entwicklung des SRI für die Ariane 4 ist lückenhaft, und einige der Personen, die die ursprünglichen Designentscheidungen getroffen hatten, waren bereits im Ruhestand.

Wir wissen in keiner quantifizierbaren Weise, wie oft sich dieses Muster in der heute für den Flug qualifizierten Avionik wiederholt. Die Reformen bei der ESA nach der Ariane 5 brachten einen präziseren Entwicklungsstandard hervor, ECSS, doch das zugrunde liegende Problem – wiederverwendete Komponenten, die implizite Annahmen über ihr Trägerfahrzeug mit sich führen – ist ebenso sehr eine Frage der Kultur wie des Prozesses, und Kultur lässt sich nur schwer prüfen.

Und wir wissen nicht, wie viele Beinahe-Katastrophen seither stillschweigend abgefangen wurden. Fehlstarts sind sichtbar. Eine konvertierte Ganzzahl, die zufällig passte, weil die Flugbahn einen Bruchteil flacher verlief, ist es nicht.

Die vier Cluster-Satelliten wurden aus Ersatzteilen neu gebaut und im Jahr 2000 mit Sojus-Raketen gestartet. Sie arbeiteten mehr als zwanzig Jahre lang erfolgreich in Formation. In der Flugsoftware für den nächsten Start der Ariane 5 wurde die Ausrichtungsroutine vollständig entfernt.

4 июня 1996 года новая европейская ракета тяжелого класса поднялась над пологом джунглей в Куру, пролетела тридцать семь секунд и разлетелась на куски. Причиной стала строка кода на языке Ада, написанная для другой ракеты десятилетием ранее.

«Ариан-5» замерла на стартовом комплексе ELA-3 в Centre Spatial Guyanais во Французской Гвиане — заправленная и впервые ведущая обратный отсчет. На борту находились четыре идентичных спутника для Cluster mission — программы Европейского космического агентства по изучению взаимодействия солнечного ветра с магнитосферой Земли. Каждый из них был плодом почти десятилетней работы. Сама ракета-носитель обошлась агентству примерно в семь миллиардов долларов и десять лет разработки. Старт состоялся в 12:34 UTC. Ракета чисто ушла со стола, легла на заданный курс и в течение тридцати шести секунд делала именно то, что от нее требовалось.

На отметке T+36,7 секунды, когда горизонтальная скорость превысила все значения, которые старая Ariane 4 когда-либо достигала на этом этапе полета, активная инерциальная система навигации обнаружила то, что интерпретировала как катастрофический внутренний сбой, и отключилась. Управление перешло к резервному блоку, который вышел из строя по той же причине на семьдесят две миллисекунды раньше. Оставшись без навигационных данных, бортовой компьютер принял диагностические битовые комбинации от отключившейся инерциальной системы за полетные данные и отдал команду на максимальное отклонение сопел двигателей. Ракета резко завалилась, аэродинамические нагрузки оторвали ускорители от основной ступени, и система безопасности полигона инициировала самоликвидацию на отметке T+39 секунд. Оборудование стоимостью около полумиллиарда долларов обрушилось обломками в мангровые болота.

Семистрочное преобразование

Комиссия Лайонса (Lions Commission) под председательством французского математика Жака-Луи Лайонса представила отчет спустя шесть недель. Этот доклад — один из самых образцовых документов технической экспертизы в истории программной инженерии. Ошибка крылась в инерциальной системе отсчета SRI, чье программное обеспечение было полностью унаследовано от «Ариан-4». Внутри SRI подпрограмма измеряла горизонтальное смещение ракеты — значение, полезное только до старта для юстировки платформы. Она преобразовывала 64-битное число с плавающей запятой, представляющее это смещение, в 16-битное знаковое целое число. На «Ариан-4» горизонтальные скорости, достигаемые во время окна юстировки, никогда не превышали потолка в 32 767 — предела для 16-битного знакового целого. На «Ариан-5», имевшей более крутую и быструю траекторию, они его превысили.

Преобразование было написано на языке Ada и, согласно архитектуре языка, вызывало исключение «ошибка операнда» (Operand Error) при переполнении. В модуле было семь переменных, нуждавшихся в защите от подобных ошибок. Три остались незащищенными на том основании, что, согласно анализу, их значения никогда не могли превысить безопасные пределы — анализу, проведенному для «Ариан-4». Переменная горизонтального смещения была одной из этих трех. Когда сработало исключение, обработчик сбросил внутреннее состояние SRI на шину данных и остановил процессор. Резервная система SRI, выполнявшая идентичный код с идентичными входными данными, отключилась точно так же несколькими циклами ранее. Бортовой компьютер прочитал диагностический дамп так, словно это были данные об ориентации. Все последующее было неизбежно.

Хуже того: процедура юстировки вообще не должна была работать в полете. Она существовала лишь для подстраховки на случай непредвиденных обстоятельств при обратном отсчете «Ариан-4», когда поздняя задержка могла потребовать перенастройки инерциальной платформы без перезапуска всей последовательности. В процедуре отсчета «Ариан-5» такой возможности предусмотрено не было. Код оставался активным во время полета только потому, что никто его не удалил.

Что упустила экспертиза

Отчет Лайонса беспощаден в вопросе о том, почему это не было замечено раньше. Система SRI была сертифицирована отдельно по спецификации, которая не учитывала траекторию «Ариан-5». Все программное обеспечение полета тестировалось в симуляции с замкнутым контуром, но саму систему SRI заменили симулятором, а не реальным блоком, на том основании, что поведение реального устройства уже было известно. Реальные полетные значения переменной горизонтального смещения никогда не прогонялись через настоящий код преобразования на земле. Первая встреча носителя с собственной траекторией произошла непосредственно во время запуска.

Читая это, возникает соблазн списать катастрофу на «целочисленное переполнение» и двигаться дальше. Более глубокий урок, который извлекла комиссия, касался повторного использования. Считалось, что компоненты, прошедшие квалификацию для одного аппарата, подходят и для другого, раз интерфейсы совпадают. Предположение было разумным. Оно также было ошибочным, и у каждого участника цепочки проверяющих, которые могли бы поставить его под сомнение, была веская причина этого не делать.

Чего мы до сих пор не знаем

Нам известно, в чем заключалась ошибка. Менее ясно, почему носитель 1996 года все еще выполнял участки кода, существовавшие только для обслуживания процедуры отсчета из 1980-х. Документация со времен разработки SRI для «Ариан-4» скудна, а некоторые из людей, принимавших первоначальные проектные решения, уже вышли на пенсию.

Мы не знаем в измеримых величинах, как часто этот сценарий повторяется в современной сертифицированной авионике. Реформы ЕКА после крушения «Ариан-5» привели к созданию более чистого стандарта разработки ECSS, но коренная проблема — повторно используемые компоненты, несущие в себе неявные предположения о носителе, — это вопрос столько же культуры, сколько и процесса, а культуру трудно подвергнуть аудиту.

И мы не знаем, сколько потенциально опасных ситуаций с тех пор было тихо поглощено системой. Неудачи при запуске на виду. Целое число, которое случайно уместилось в лимит, потому что траектория оказалась на долю положе, — нет.

Четыре спутника Cluster были заново построены из запасных частей и запущены на ракетах «Союз» в 2000 году. Они успешно проработали в группе более двадцати лет. В полетном программном обеспечении для следующего запуска «Ариан-5» подпрограмма юстировки была удалена полностью.

1996년 6월 4일, 유럽의 신형 대형 로켓이 쿠루의 정글 수관 위로 솟아올랐다. 37초간 비행하던 로켓은 스스로를 찢어발기며 산산조각 났다. 원인은 10년 전 전혀 다른 로켓을 위해 작성된 에이다 코드 단 한 줄이었다.

아리안 5호가 프랑스령 기아나의 Centre Spatial Guyanais 내 ELA-3 발사대에 세워졌다. 연료 주입을 마치고 첫 카운트다운을 시작했다. 탑재체는 태양풍이 지구 자기권과 어떻게 상호작용하는지 연구하기 위한 유럽 우주국의 Cluster mission용 동일 위성 4기였다. 각각 약 10년의 노력이 집약된 산물이었다. 발사체 자체의 개발에는 약 10년의 시간과 70억 달러에 달하는 예산이 투입되었다. 이륙은 UTC 12시 34분에 이루어졌다. 로켓은 깔끔하게 치솟아 계획된 방향으로 기수를 돌렸고, 36초 동안은 정확히 의도된 대로 움직였다.

이륙 후 36.7초, 이전의 Ariane 4가 비행 중 경험했던 것보다 높은 수평 속도에 도달하자, 기내에 장착된 활성 관성 기준 시스템이 이를 치명적인 내부 결함으로 판단하고 스스로 가동을 중단했다. 제어권은 백업 장치로 넘어갔으나, 백업 장치 역시 이미 72밀리초 전에 동일한 이유로 고장이 난 상태였다. 항법 데이터가 사라지자 온보드 컴퓨터는 멈춰버린 관성 시스템에서 흘러나오는 진단용 비트 패턴을 비행 데이터로 오인하여 엔진 노즐에 최대 편향을 명령했다. 로켓은 급격히 기울어졌고, 공기역학적 하중을 견디지 못한 부스터가 본체에서 떨어져 나갔으며, 지상 안전 시스템은 이륙 39초 만에 자폭 장치를 작동시켰다. 약 5억 달러 상당의 하드웨어가 맹그로브 늪지 위로 비처럼 쏟아져 내렸다.

7행의 변환

프랑스 수학자 자크 루이 리옹이 이끄는 Lions Commission은 6주 후 조사 결과를 발표했다. 이 보고서는 소프트웨어 공학 분야에서 가장 명료한 포렌식 문서 중 하나로 꼽힌다. 결함은 SRI라고 불리는 관성 기준 시스템에 있었다. 이 시스템의 소프트웨어는 아리안 4호에서 그대로 물려받은 것이었다. SRI 내부에는 플랫폼 정렬을 위해 발사 전 단계에서만 유효한 값인 로켓의 수평 편차를 측정하는 루틴이 있었다. 이 루틴은 해당 편차를 나타내는 64비트 부동 소수점 숫자를 16비트 부호 있는 정수로 변환했다. 아리안 4호의 경우 정렬 시간 동안 도달하는 수평 속도가 16비트 정수의 최대치인 32,767을 넘지 않았으나, 궤도가 더 가파르고 빠른 아리안 5호는 이를 초과했다.

이 변환 코드는 Ada로 작성되었으며, 언어 설계 특성상 부동 소수점이 오버플로될 때 '피연산자 오류(Operand Error)'를 발생시키게 되어 있었다. 모듈 내의 변수 중 7개가 이러한 오류에 대비한 보호 조치 대상이었으나, 그중 3개는 아리안 4호 당시의 분석 결과를 근거로 수치가 안전 한계를 절대 넘지 않을 것이라는 이유로 보호되지 않은 채 방치되었다. 수평 편차 변수가 바로 그중 하나였다. 예외 상황이 발생하자 핸들러는 SRI의 내부 상태 데이터를 데이터 버스에 쏟아낸 뒤 프로세서를 정지시켰다. 동일한 입력값으로 동일한 코드를 실행하던 백업 SRI도 몇 사이클 앞서 이미 정지된 상태였다. 온보드 컴퓨터는 이 진단용 데이터 덤프를 기체 자세 데이터로 읽어 들였다. 이후의 파멸은 피할 수 없는 수순이었다.

설상가상으로, 정렬 루틴은 비행 중에 실행될 이유조차 없었다. 이 코드는 아리안 4호의 카운트다운 중 지연이 발생할 경우 시퀀스를 재시작하지 않고도 관성 플랫폼을 재정렬해야 하는 비상 상황에 대비해 만들어진 것이었다. 아리안 5호의 카운트다운 절차에는 그런 상황 자체가 없었다. 단순히 아무도 삭제하지 않았기 때문에 비행 중에도 코드가 살아 있었던 것이다.

검토 과정에서 놓친 것들

리옹 보고서는 왜 이 결함을 사전에 발견하지 못했는지에 대해 가차 없는 비판을 가했다. SRI는 아리안 5호의 궤도 데이터가 포함되지 않은 사양에 따라 개별적으로 적격성 평가를 받았다. 전체 비행 소프트웨어는 폐쇄 루프 시뮬레이션 테스트를 거쳤지만, SRI 실물 장치는 거동이 이미 알려져 있다는 이유로 시뮬레이터로 대체되었다. 발사체의 실제 비행 중 수평 편차 값은 지상에서 실제 변환 코드를 한 번도 통과해 본 적이 없었다. 발사체가 자신의 실제 궤도와 처음 맞닥뜨린 순간은 바로 실제 발사 때였다.

이 사고를 접하면 단순히 '정수 오버플로'의 문제로 치부하고 넘어가고 싶은 유혹이 생긴다. 그러나 조사 위원회가 도출한 더 깊은 교훈은 '재사용'에 관한 것이었다. 한 기체에서 검증된 부품은 인터페이스만 맞으면 다른 기체에서도 유효할 것이라고 간주되었다. 이는 합리적인 가설처럼 보였으나 틀린 생각이었고, 이를 의심했어야 할 수많은 검토자에게는 각자 나름의 타당한 방치 사유가 있었다.

우리가 여전히 알지 못하는 것

우리는 버그의 정체를 안다. 하지만 1996년의 발사체가 왜 1980년대 카운트다운 절차만을 위한 코드 경로를 여전히 품고 있었는지는 불분명하다. 초기 아리안 4호 SRI 개발 당시의 문서는 부실했고, 설계 결정을 내렸던 이들 중 일부는 이미 은퇴한 뒤였다.

오늘날 비행 적격성을 갖춘 항공 전자 기기들에서 이러한 패턴이 얼마나 자주 반복되고 있는지도 정량적으로 알 길이 없다. 아리안 5호 사고 이후 ESA가 도입한 개혁은 더 정교한 개발 표준인 ECSS를 낳았으나, 탑재될 기체에 대한 암묵적 가정을 품은 채 재사용되는 부품이라는 근본적인 문제는 프로세스만큼이나 문화의 영역이며, 문화는 감사가 어렵다.

또한 그동안 얼마나 많은 아차 사고들이 조용히 묻혔는지도 알 수 없다. 발사 실패는 눈에 띄지만, 궤도가 미세하게 완만했던 덕분에 정수로 변환된 값이 아슬아슬하게 한계 내에 머물렀던 사례는 드러나지 않기 때문이다.

네 기의 클러스터 위성은 예비 부품으로 다시 제작되어 2000년 소유즈 로켓에 실려 발사되었다. 이들은 대형을 유지하며 20년 넘게 임무를 수행했다. 아리안 5호의 다음 발사를 위한 비행 소프트웨어에서는 정렬 루틴이 완전히 제거되었다.

Ariane 5 Explosion