El Ariane 5 explotó por un código que funcionaba perfectamente en el Ariane 4

Treinta y siete segundos después del despegue, el nuevo cohete europeo giró bruscamente y se salió de su trayectoria. Instantes después se partió y se autodestruyó sobre la zona de lanzamiento de Kourou, en la Guayana Francesa.

Era el Ariane 5 en su primer vuelo. A bordo iban los cuatro satélites científicos Cluster. Ningún motor había explotado. Ninguna estructura había fallado por sí sola.

La causa fue un número que no cabía.

El número era demasiado grande

El vuelo 501 despegó el 4 de junio de 1996. Durante el primer medio minuto todo parecía normal. Entonces, los dos sistemas de referencia inercial del cohete, los equipos que le indican al ordenador de vuelo hacia dónde apunta el vehículo y cómo se mueve, se apagaron con una fracción de segundo de diferencia.

La comisión investigadora independiente, presidida por el matemático francés Jacques-Louis Lions, rastreó el fallo hasta una sola operación del software de referencia inercial: convertir un valor de coma flotante de 64 bits en un entero con signo de 16 bits. Ese valor, un resultado interno de alineación llamado BH, o sesgo horizontal, era mayor de lo que puede almacenar un entero de 16 bits. La conversión provocó un "operand error". El software no tenía ningún manejador para ese error, así que el procesador hizo lo que exigía su especificación: se apagó.

La unidad de respaldo ya había hecho lo mismo 72 milisegundos antes. Ejecutaba el mismo software con los mismos datos, así que se topó con el mismo problema. La redundancia que debía proteger la misión simplemente falló dos veces.

Ese código no necesitaba estar funcionando

El detalle más inquietante es que el cálculo que falló no tenía ninguna utilidad una vez que el cohete abandonaba la plataforma.

La función de alineación pertenecía a la fase previa al lanzamiento. En el Ariane 4 estaba diseñada para seguir funcionando unos 40 segundos tras el despegue, de modo que una cuenta atrás interrumpida en el último momento pudiera reanudarse rápido sin una larga realineación. El Ariane 5 no necesitaba ese comportamiento. Aun así, la función se conservó para mantener la uniformidad con el sistema probado del Ariane 4.

En el Ariane 4, el código funcionaba bien. Pero el Ariane 5 seguía una trayectoria inicial distinta, con una velocidad horizontal bastante mayor. Eso llevó a BH muy por encima de cualquier valor que hubiera producido el Ariane 4, y por encima de lo que podía contener la variable de 16 bits.

El software no tenía un "bug" en el sentido habitual. Hizo exactamente aquello para lo que fue escrito. Lo que había cambiado era el mundo a su alrededor.

Una decisión deliberada, tomada por buenas razones

Es tentador imaginar a un programador descuidado que olvidó comprobar un rango. La comisión encontró algo más instructivo.

En esa parte del código se habían analizado siete variables por posible desbordamiento. Cuatro estaban protegidas. Tres, entre ellas BH, quedaron sin protección, en parte porque los ingenieros trabajaban con un objetivo de carga máxima del procesador del 80 por ciento y en parte porque habían concluido que esos valores estaban limitados físicamente o tenían un amplio margen. Esa conclusión era cierta para el Ariane 4. Nadie volvió a comprobarla para el Ariane 5.

La comisión señaló además que los datos de trayectoria del Ariane 5 no se habían incluido en los requisitos del sistema de referencia inercial. Así que las pruebas nunca le dieron al sistema los números que habrían revelado el problema. El sistema también se simuló en lugar de integrarse en las pruebas completas de lazo cerrado. El informe dice sin rodeos que el fallo podría haberse detectado.

Después, el ordenador leyó un mensaje de error como datos de vuelo

Apagarse fue solo la mitad del daño. Cuando falló la unidad activa, emitió un patrón de bits de diagnóstico. El ordenador de a bordo interpretó ese patrón como datos de vuelo reales.

Convencido de que el cohete tenía una actitud muy desviada, el ordenador ordenó la deflexión máxima de las toberas de los propulsores sólidos y del motor principal. El cohete alcanzó un ángulo de ataque de más de 20 grados. Las cargas aerodinámicas arrancaron los propulsores de la etapa central, y esa separación activó la autodestrucción unos 39 segundos después del despegue.

Debajo de todo había una filosofía de diseño. Como dijo la comisión, la especificación trataba una excepción de software como si fuera un fallo aleatorio de hardware, algo que un respaldo podría absorber. Pero un error de diseño de software no es aleatorio. Dos copias del mismo código fallan juntas.

Lo que la comisión pidió a los ingenieros

Las recomendaciones del informe parecen una lista de verificación que todavía sirve a los equipos de software de hoy:

• Desactivar las funciones que no se necesitan durante el vuelo. El código que no se ejecuta no puede fallar.
• Probar el sistema real en lazo cerrado, con datos realistas, no solo con componentes simulados.
• No permitir que un sensor deje de enviar datos por completo. Los mejores datos disponibles son preferibles al silencio.
• Revisar las suposiciones implícitas del software reutilizado, sobre todo los rangos de valores que se dan por sentados.
• Incluir los datos reales de trayectoria en las especificaciones y en los requisitos de prueba.

La lección trata de la reutilización, no de una línea de código

El Ariane 501 suele resumirse como "un número de 64 bits destruyó un cohete". Es correcto, pero no capta lo esencial. El desbordamiento fue el síntoma. La causa fue que un componente bien probado llevó una suposición de un sistema antiguo a uno nuevo, y que nadie tenía asignada la tarea de volver a comprobarla.

En 1997, Jean-Marc Jézéquel y Bertrand Meyer lo llamaron un error de reutilización. Su argumento era que el código reutilizable necesita tener sus suposiciones escritas donde puedan verificarse, no guardadas en la cabeza de quienes lo escribieron.

Todo equipo de software hereda código que "siempre ha funcionado". La pregunta útil no es si ese código es bueno. Es: ¿en qué condiciones funcionó, y siguen siendo ciertas esas condiciones?

El software del Ariane 4 respondió correctamente a esa pregunta para el Ariane 4. El vuelo 501 es lo que ocurrió cuando nadie volvió a hacerla.

Fuentes

• ARIANE 5 Flight 501 Failure, informe de la comisión investigadora (ESA/CNES, julio de 1996)
• Comunicado de prensa de la ESA 33-1996: Ariane 501, presentación del informe de la comisión investigadora
• Comunicado de prensa de la ESA: Flight 501 failure, primera información
• Jean-Marc Jézéquel y Bertrand Meyer, "Design by Contract: The Lessons of Ariane", IEEE Computer, 1997
• Douglas N. Arnold, Universidad de Minnesota, "The Explosion of the Ariane 5"
• Imagen destacada: un Ariane 5 en la plataforma de lanzamiento en 2021 (no el vuelo 501). NASA/Bill Ingalls, Wikimedia Commons, dominio público (public domain)