¿Cuál fue el impacto histórico del vuelo 501 de Ariane 5?

La desintegración del cohete Ariane 5 37 segundos después del lanzamiento en su viaje inaugural ( Vuelo 501 ) se conoce comúnmente como uno de los errores de software más caros en la historia ¹ :

La Agencia Espacial Europea tardó 10 años y $ 7 mil millones en producir Ariane 5, un cohete gigante capaz de lanzar un par de satélites de tres toneladas en órbita con cada lanzamiento y tenía la intención de darle a Europa una supremacía abrumadora en el negocio espacial comercial.

Todo lo que se necesitó para explotar ese cohete en menos de un minuto en su viaje inaugural en junio pasado, esparciendo escombros ardientes por los manglares de la Guayana Francesa, fue un pequeño programa de computadora que intentaba introducir un número de 64 bits en un espacio de 16 bits.

Un error, un accidente. De todas las líneas de código descuidadas registradas en los anales de la informática, esta puede ser la más devastadoramente eficiente. A partir de entrevistas con expertos en cohetería y un análisis preparado para la agencia espacial, emerge un camino claro desde un error aritmético hasta la destrucción total.

¿Qué cambios importantes provocó el fracaso de Flight 501 y las investigaciones posteriores inspiraron a la investigación de sistemas críticos de seguridad y pruebas de software?

No busco una explicación del error en sí, sino una explicación del impacto histórico del error, en términos de investigación que se inspiró o se relacionó directamente con la (s) investigación (es) de la falla. Por ejemplo, este documento concluye:

Hemos utilizado el análisis estático para:

• verificar la inicialización de variables,
• proporcionar la lista exhaustiva de posibles conflictos de acceso a datos para variables compartidas,
• enumere exhaustivamente los posibles errores de tiempo de ejecución de la semántica de Ada.

Hasta donde sabemos, esta es la primera vez que se utilizan técnicas de análisis estático basadas en booleanos y no booleanas para validar programas industriales.

Del mismo modo, este documento ^(pdf) señala:

Se han utilizado análisis de programas estáticos basados ​​en interpretación abstracta para el análisis estático del software ADA incorporado del lanzador Ariane 5 y el ARD. El analizador de programa estático tiene como objetivo la detección automática de la de fi nitud, potencialidad, imposibilidad o inaccesibilidad de errores de tiempo de ejecución tales como sobrevuelos escalares y de punto flotante, errores de índice de matriz, divisiones por cero y excepciones aritméticas relacionadas, variables no inicializadas, carreras de datos en estructuras de datos compartidas, etc. El analizador pudo descubrir automáticamente el error de vuelo Ariane 501. El análisis estático del software de seguridad incorporado (como el software de aviónica) es muy prometedor .

Me encantaría una explicación detallada del impacto que este evento único tuvo en los enfoques y herramientas de prueba de software.

_{¹ La cifra de $ 7 mil millones posiblemente se refiere al costo total del proyecto Ariane 5, Wikipedia informa que el fracaso resultó en una pérdida de más de $ 370 millones. Sigue siendo un fracaso bastante costoso, pero no se acerca a la cifra de $ 7 mil millones.}

Técnicamente hablando, fue más un caso de " podredumbre de software ". El software de control de vuelo se recicló del cohete Ariane 4 anterior, un movimiento sensato dado lo caro que es desarrollar software, especialmente cuando es un software de misión crítica que debe ser probado y verificado con estándares mucho más rigurosos que la mayoría de los softwares comerciales.

Desafortunadamente, nadie se molestó en probar qué efecto tendría el cambio en el entorno operativo, o si lo hicieran, no lo hicieron con un estándar suficientemente exhaustivo.

El software fue creado para esperar que ciertos parámetros nunca excedan ciertos valores (empuje, aceleración, tasas de consumo de combustible, niveles de vibración, etc.). En vuelo normal en un Ariane 4, esto no fue un problema porque esos parámetros nunca alcanzarían valores no válidos sin que algo ya estuviera espectacularmente mal. El Ariane 5, sin embargo, es mucho más poderoso y los rangos que parecerían tontos en el 4 podrían suceder fácilmente en el 5.

No estoy seguro de qué parámetro estaba fuera de rango (podría haber sido la aceleración, tendré que verificarlo), pero cuando lo hizo, el software no pudo hacer frente y sufrió un desbordamiento aritmético por el cual hubo Se ha implementado un código de comprobación y recuperación de errores insuficiente. La computadora de guía comenzó a enviar basura a los gimbals de la boquilla del motor, que a su vez comenzaron a apuntar la boquilla del motor al azar. El cohete comenzó a caer y romperse, y el sistema automático de autodestrucción detectó que el cohete ahora estaba en una actitud irrecuperable insegura y terminó el trabajo.

Para ser honesto, este incidente probablemente no enseñó nuevas lecciones, ya que el tipo de problemas se han descubierto antes en todo tipo de sistemas, y ya existen estrategias para tratar de encontrar y corregir errores. Lo que hizo el incidente fue recordar que ser negligente al seguir esas estrategias puede tener enormes consecuencias, en este caso millones de dólares en hardware destruido, algunos clientes extremadamente enojados y una fea abolladura en la reputación de Arianespace.

Este caso particular fue especialmente evidente porque un atajo tomado para ahorrar dinero terminó costando una gran cantidad, tanto en términos de dinero como de pérdida de reputación. Si el software se hubiera probado con la misma solidez en un entorno simulado Ariane 5 que cuando se desarrolló originalmente para Ariane 4, el error seguramente saldría a la luz mucho antes de que el software se instalara en el hardware de lanzamiento y se pusiera al mando de Un vuelo real. Además, si un desarrollador de software hubiera arrojado deliberadamente alguna información sin sentido en el software, entonces el error podría haberse detectado incluso en la era de Ariane 4, ya que habría resaltado el hecho de que la recuperación de error que estaba en su lugar era inadecuada.

En resumen, en realidad no enseñó nuevas lecciones, pero se dio cuenta de los peligros de no recordar las viejas. También demostró que el entorno dentro del cual opera un sistema de software es tan importante como el propio software. El hecho de que el software sea verificablemente correcto para el entorno X no significa que sea adecuado para su propósito en el entorno similar pero distinto Y. Finalmente, destacó la importancia de que el software de misión crítica sea lo suficientemente robusto para lidiar con circunstancias que no deberían sucedió

Contraste el vuelo 501 con el Apolo 11 y sus problemas informáticos. Si bien el software LGC sufrió una falla grave durante el aterrizaje, fue diseñado para ser extremadamente robusto y pudo permanecer en un estado operativo a pesar de las alarmas de software que se activaron, sin poner en peligro a los astronautas y aún así poder Completa su misión.

Fue principalmente un problema de reutilización y de gestión y no uno de codificación. De mis recuerdos (probablemente estoy equivocando algunas cosas) del informe.

• Un subsistema había sido diseñado para Ariane IV. Las trayectorias de Ariane IV no podían provocar el desbordamiento y luego se decidió deliberadamente que si ocurría, era un problema de hardware y cerrar el subsistema e ir al repuesto era lo correcto.

• para Ariane V, se decidió reutilizar ese subsistema y no revisar las suposiciones y el código, sino confiar en las pruebas.

• Además, se decidió abandonar la prueba completa.

Diferentes parámetros de vuelo de Ariane V hicieron que ocurriera el desbordamiento. Apaga la primaria. Apaga el repuesto. Autodestrucción

Cosas adicionales que recuerdo:

• el subsistema en el momento del desbordamiento ya no era útil. Se podría argumentar que su falla no debería haber desencadenado la autodestrucción. (Por otro lado, la complejidad añadida en sí misma podría ser una fuente de problemas).

• se enviaron datos de depuración a un bus cuando no debería. No recuerdo lo específico.

Como otros han mencionado, causó que la industria en general volviera a examinar el concepto de reutilización y lo ubicara en un marco de referencia más amplio por el cual los componentes no se evalúan de forma aislada sino en el contexto de todo el sistema. Esto reduce significativamente el atractivo de la reutilización, ya que incluso si un componente puede reutilizarse sin cambios, aún debe analizarse con un nuevo conjunto de supuestos. Otro corolario es que el hardware de respaldo que ejecuta el mismo software no es tan atractivo, ya que la mayoría del hardware moderno es mucho más confiable que el software moderno. He oído que algunos contratos de defensa requieren dos sistemas de software separados desarrollados por diferentes equipos que utilizan diferentes tecnologías que trabajan desde la misma especificación para verificar la implementación adecuada.