Vuelo Ariane V88

Vuelo Ariane V88 fue el vuelo inaugural fallido del cohete Arianespace Ariane 5, vehículo núm. 501, el 4 de junio de 1996. Llevaba la nave espacial Cluster, una constelación de cuatro satélites de investigación de la Agencia Espacial Europea.

El lanzamiento terminó en un fracaso debido a múltiples errores en el diseño del software: el código inactivo, destinado únicamente a Ariane 4, con una protección inadecuada contra el desbordamiento de enteros provocó una excepción manejada de manera inapropiada, deteniendo todo el sistema de navegación inercial que de otro modo no se vería afectado. Esto provocó que el cohete se desviara de su trayectoria de vuelo 37 segundos después del lanzamiento, comenzara a desintegrarse bajo altas fuerzas aerodinámicas y finalmente se autodestruyera a través de su sistema automatizado de terminación de vuelo. La falla se conoce como uno de los errores de software más infames y costosos de la historia. El fracaso resultó en una pérdida de más de 370 millones de dólares.

Error de lanzamiento

El Ariane 5 reutilizó el código de la plataforma de referencia inercial del Ariane 4, pero la primera parte de la trayectoria de vuelo del Ariane 5 se diferenciaba del Ariane 4 por tener valores de velocidad horizontal más altos. Esto provocó que un valor interno BH (sesgo horizontal) calculado en la función de alineación fuera inesperadamente alto. La función de alineación estuvo operativa durante aproximadamente 40 segundos de vuelo, lo cual se basó en un requisito de Ariane 4, pero no sirvió para nada después del despegue en el Ariane 5. Los valores mayores de BH provocaron una conversión de datos de un sistema flotante de 64 bits. El número de punto a un valor entero con signo de 16 bits se desborda y provoca una excepción de hardware. Los programadores habían protegido solo cuatro de siete variables críticas contra el desbordamiento para mantener el objetivo de carga de trabajo máxima requerida del 80% para la computadora del sistema de referencia inercial a bordo, y se basaron en suposiciones que eran correctas para el Ariane 4, pero no para el Ariane 5., trayectoria sobre el posible rango de valores para las tres variables desprotegidas. La excepción detuvo ambos módulos del sistema de referencia inercial, aunque estaban destinados a ser redundantes. El módulo activo presentó un patrón de bits de diagnóstico a la computadora de a bordo que fue interpretado como datos de vuelo, causando en particular desviaciones totales de las boquillas de los propulsores sólidos y del motor principal Vulcain. Esto provocó un ángulo de ataque de más de 20 grados, lo que provocó la separación de los propulsores del escenario principal, la activación del sistema de autodestrucción del lanzador y la destrucción del vuelo.

El informe oficial sobre el accidente (realizado por una comisión de investigación encabezada por Jacques-Louis Lions) señaló que "Un tema subyacente en el desarrollo de Ariane 5 es el sesgo hacia la mitigación de fallos aleatorios". El proveedor del sistema de navegación inercial (SRI) solo siguió las especificaciones que le dieron, que estipulaban que en caso de detectarse alguna excepción el procesador debía detenerse. La excepción que se produjo no se debió a una falla aleatoria sino a un error de diseño. La excepción se detectó, pero se manejó de manera inapropiada porque se había adoptado la opinión de que el software debería considerarse correcto hasta que se demuestre que tiene un error. [...] Aunque el fallo se debió a un error sistemático en el diseño del software, se pueden introducir mecanismos para mitigar este tipo de problema. Por ejemplo, las computadoras dentro de los SRI podrían haber seguido brindando sus mejores estimaciones de la información de actitud requerida. Hay motivos para preocuparse de que se permita, o incluso se exija, una excepción de software para provocar que un procesador se detenga mientras maneja equipos de misión crítica. De hecho, la pérdida de una función de software adecuada es peligrosa porque el mismo software se ejecuta en ambas unidades SRI. En el caso del Ariane 501, esto provocó el apagado de dos equipos críticos que aún estaban en buen estado."

Otros problemas identificados en el informe se centraron en las pruebas:

• El objetivo del proceso de examen, que incluye a todos los principales asociados del programa Ariane 5, es validar las decisiones de diseño y obtener la calificación de vuelo. En este proceso, no se analizaron plenamente las limitaciones del software de alineación y no se realizaron las posibles implicaciones de permitirle seguir funcionando durante el vuelo.
• La especificación del sistema de referencia inercial y las pruebas realizadas a nivel de equipo no incluían específicamente los datos de trayectoria Ariane 5. En consecuencia, la función de reajuste no fue probada bajo condiciones simuladas de vuelo Ariane 5, y el error de diseño no fue descubierto.
• Habría sido técnicamente factible incluir casi todo el sistema de referencia inercial en las simulaciones generales del sistema que se realizaron. Por varias razones se decidió utilizar la salida simulada del sistema de referencia inercial, no el sistema real o su simulación detallada. Si se hubiera incluido el sistema, se podría haber detectado el fallo. Las simulaciones posteriores al vuelo se han llevado a cabo en un ordenador con software del sistema de referencia inercial y con un entorno simulado, incluyendo los datos de trayectoria real del vuelo Ariane 501. Estas simulaciones han reproducido fielmente la cadena de eventos que conducen al fracaso de los sistemas de referencia inerciales.

Otra perspectiva del fallo, basada en la ingeniería de sistemas, se centra en los requisitos:

• Los rangos de variables como la velocidad horizontal y la cantidad BH calculada de ella deberían haberse cuantificado explícitamente. En cambio, se asumió un rango de 16 bits.
• La tarea de alineación debería haberse desactivado en un momento apropiado. En su lugar, la tarea de alineación se ejecutó después del despegue.
• Se debería haber analizado un modelo de fracaso de las plataformas de referencia inerciales para asegurar que el servicio se entregara continuamente durante todo el vuelo, en lugar de asumir que en la mayoría de un módulo fallaría. En cambio, ambos módulos fallaron, y en lugar de matar el vuelo con gracia, emiten mensajes de diagnóstico que se interpretaron como datos de vuelo.

Carga útil

El grupo estaba formado por cuatro naves espaciales cilíndricas estabilizadas por giro de 1.200 kilogramos (2.600 lb), alimentadas por células solares de 224 vatios. La nave espacial debía haber volado en formación tetraédrica y estaba destinada a realizar investigaciones sobre la magnetosfera de la Tierra. Los satélites se habrían colocado en órbitas muy elípticas; 17.200 por 120.600 kilómetros (10.700 por 74.900 millas), con una inclinación de 90 grados con respecto al ecuador.

Consecuencias

Tras el fallo, se construyeron cuatro satélites del Grupo II de repuesto. Estos fueron lanzados en pares a bordo de cohetes Soyuz-U/Fregat en 2000.

El fracaso del lanzamiento llamó la atención del público en general, los políticos y los ejecutivos sobre los altos riesgos asociados con los sistemas informáticos complejos, lo que resultó en un mayor apoyo a la investigación para garantizar la confiabilidad de los sistemas críticos para la seguridad. El posterior análisis automatizado del código Ariane (escrito en Ada) fue el primer ejemplo de análisis de código estático a gran escala mediante interpretación abstracta.

El fracaso también perjudicó el excelente historial de éxitos de la familia de cohetes de la Agencia Espacial Europea, marcado por la alta tasa de éxito del modelo Ariane 4. No fue hasta 2007 que los lanzamientos del Ariane 5 fueron reconocidos como tan fiables como los del modelo predecesor.