El fallo del vuelo 501 del Ariane 5 quizá se haya convertido en el primer bug informático de consecuencias catastróficas.
En términos generales, el Sistema de Control de Vuelo del Ariane-5 es de un diseño standard. La orientación de la lanzadera y sus movimientos en el espacio son medidos por un Sistema de Referencia Inercial (SRI). Éste tiene su propio computador interno, en el cual los ángulos y las velocidades se calculan sobre la base de la información de una plataforma inercial, con giroscopios láser y acelerómetros. Los datos del SRI se transmiten a través del bus de datos a la Computadora de a Bordo (OBC), la cual ejecuta el programa de vuelo y controla las bocas de los propulsores sólidos y el motor criogénico Vulcain, por medio de servoválvulas y actuadores hidráulicos.
Con el objetivo de mejorar la fiabilidad hay una redundancia considerable en el equipos. Hay dos SRIs operando en paralelo, con idénticos hardware y software. Un SRI está activo y el otro está en stand-by, y si el OBC detecta que el SRI activo ha fallado inmediatamente conmuta al otro, siempre y cuando esta unidad funcione correctamente. Del mismo modo hay dos OBCs, y algunas otras unidades en el Sistema de Control de Vuelo están también duplicadas.
Un estudio preliminar mostró que el cohete funcionaba perfectamente hasta H0+36 (36 segundos después del despegue). En ese instante, el Sistema de Referencia Inercial de reserva (SRI1) comenzó a fallar. Acto seguido, el Sistema de Referencia Inercial principal (SRI2) fallaba también. Las bocas de los dos propulsores, seguidas por el motor principal Vulcan giran bruscamente, provocando un giro brusco de todo el cohete. El fallo ya es inevitable. Se activa el sistema de autodestrucción, rompiendo los enlaces entre los propulsores y la etapa principal, siguiendo lo programado en tales circunstancias.
Un estudio más detallado permitió establecer la siguiente cadena de sucesos:
* La lanzadera se empezó a desintegrar hacia H0+39 segundos a causa de las altas cargas aerodinámicas debidas al ángulo de ataque de más de 20 grados que provocaron la separación de los propulsores de la etapa principal, disparando el mecanismo de autodestrucción de la lanzadera
* Este ángulo de ataque fue causado por deflexiones límite de las bocas de los propulsores sólidos y del motor principal Vulcain.
* Estas deflexiones de las bocas fueron ordenadas por el software del OBC sobre la base de los datos transmitidos por el Sistema de Referencia Inercial activo (SRI 2). Parte de estos datos en ese momento no contenían datos de vuelo correctos, pero mostraban la plantilla de diagnóstico de la computadora del SRI 2, por lo cual fueron interpretados como datos de vuelo.
* La razón por la que el SRI 2 no enviaba datos de orientación correctos fue que la unidad declaró un fallo debido a una excepción de software
* El OBC no pudo conmutar al SRI de reserva, el SRI 1 porque dicha unidad ya había dejado de funcionar durante el ciclo de datos previo (periodo de 72 milisegundos) por la misma razón que el SRI 2.
* La excepción de sofware interna del SRI fue causada durante la ejecución de una conversión de datos desde coma flotante a 64 bits hasta valor entero con signo de 16 bits. El número en coma flotante que fue convertido tenía un valor mayor del que podía ser representado por un entero con signo de 16 bits. Esto dio lugar a un Error de Operando. Las instrucciones de conversión de datos (en código Ada) no estaban protegidas de causar un Error de Operando, aunque otras conversiones de variables comparables en el mismo lugar en el código estaban protegidas.
* El error ocurrió en una parte del software que únicamente realiza alineamientos de la plataforma inercial. Este módulo software computa resultados significativos solamente antes del despegue. Tan pronto como la lanzadera despega, esta función deja de ser útil.
* La función de alineamiento está operativa durante 50 segundos después del comienzo del Modo de Vuelo de los SRIs, lo cual ocurre en H0-3 segundos para Ariane-5. Consecuentemente, cuando el despegue tiene lugar, la función continúa durante aproximadamente 40 segundos de vuelo. Esta secuencia de tiempo está basada en un requerimiento de Ariane-4 y no se requiere para Ariane-5.
* El Error de Operando ocurrió debido a un valor inesperadamente alto de un resultado de una función de alineamiento interno llamado BH, Horizontal Bias, relacionado con la velocidad horizontal detectada por la plataforma. Este valor es calculado como un indicador para la precisión de alineamiento con el tiempo.
* El valor de BH era mucho más alto que el esperado porque la primera parte de la trayectoria de Ariane-5 difiere de la misma en el Ariane-4 y los resultados en valores considerablemente altos de velocidad horizontal.
Como vemos, los dos Sistemas de Referencia Inercial fallaron por una excepción de software que reseteó ambos sistemas. Sin embargo, un Sistema Inercial basa su estimación en una serie de medidas que, recursivamente, corrigen la estimación en el instante anterior. El hecho de reiniciar los sistemas hizo perder la estimación anterior y por lo tanto, inutilizo los sistemas.
La excepción ocurrió por un desbordamiento de memoria. El problema con los ordenadores es que existen infinitos números enteros, pero además, existen infinitos números reales entre cada par de números enteros. Demasiados infinitos para una cantidad limitada de memoria. Además, esos números los tenemos que codificar en memoria como números binarios, lo que dificulta los cálculos con decimales. Y por si fuera poco, cadenas binarias más grandes implican más coste de procesamiento.
Así que normalmente los números se almacenan en cadenas binarias que suelen ir desde 8 a 64 bits. Un bit es un dígito binario, es decir, puede valer 1 o 0. Con esto, podemos representar 2^64 números distintos, que no esta nada mal, aunque sigue estando lejos de infinito. Para facilitar aun más las cosas, se suelen utilizar varios formatos. Por ejemplo, si queremos representar números enteros, nos olvidamos de la parte decimal. Para números con decimales se utiliza un método de base y exponente que permite trabajar con números muy grandes con muchos decimales almacenándolos en poco espacio.
El problema es cuando estamos trabajando con enteros y al hacer la división nos sale un número con decimales, o viceversa. Entonces tenemos que convertirlos. Pero hay que tener cuidado en estos cambios, ya que normalmente los números enteros trabajan con más precisión, pero en rangos más pequeños.
Normalmente en estos casos, se suelen hacer dos cosas. La más “elegante” es programar un sistema inteligente de conversión, que nos garantiza que la conversión se va a hacer bien y no se va a perder información. Es lo que se llama una conversión protegida. El problema es que hacer esas comprobaciones requiere un tiempo de cálculo extra. La que más se suele emplear, también por comodidad, es precalcular los posibles valores que va a tener esa variable. Por ejemplo, si esa variable sirve para contar los alumnos en una clase, y el rango admisible es hasta 100 mil millones, pues sabemos que no va a haber riesgos de desbordamiento. Nos sobra. Además tiene la ventaja de que no necesita cálculos extra.
En el caso del fallo del Ariane 5, algunas variables estaban protegidas, pero la carga del computador ya era del 80%. Seguir protegiendo conversiones podría desencadenar un desbordamiento del procesador, que es aun peor. ¿Qué hicieron los ingenieros? Aplicar el segundo caso y precalcular el tamaño de la variable.
También se ha observado, que de haber seguido con el dato erróneo, y las estimaciones anteriores, se podría haber seguido con la misión. El hecho de resetear los sistemas inerciales fue crítico. Sin embargo, el gabinete de diseño del Ariane-5, nunca se planteo un error interno, y en las especificaciones solo se tenían en cuenta errores aleatorios, ante los cuales, no era aconsejable continuar. El manejo de la excepción se podría haber mejorado, pero nadie incluyó esa parte en las especificaciones del diseño.
Bien, ¿y por qué falló el sistema, siendo que se habría precalculado el límite? ¿Por qué se salio de rango la variable?
Aunque no lo parezca, la responsable final es una decisión política. Siendo claros, el Ariane-5 nunca hizo falta. Eso lo sabe cualquier persona que trabaje en la ESA. Sin embargo, el sistema político de la ESA, le obliga a comprar tecnología a los distintos países en función de la inversión que estos hacen a la ESA. Es decir, si España paga el 10% de los fondos de la ESA, esta tiene que hacer el 10% de sus compras a empresas españolas.
El Ariane-4 funcionaba perfectamente, pero había que comprar algo a Francia y Alemania. Y tenía que ser algo realmente caro para cerrar el presupuesto. Pues nada, compramos un cohete. El problema es que el coste del Ariane-5 es prohibitivo. No solo de diseño, si no también de uso. Normalmente, la calidad de un cohete se mide en el coste de poner un kilo de materia en órbita. Pues bien, aunque la carga útil del Ariane-4 es menor, el coste por kilo es mucho más barato. Así que, en las últimas fases de diseño, se vio que el cohete iba a salir muy caro y la ESA no lo compraría. Se tomó la decisión de recortar costes.
Curiosamente, en la traducción que he encontrado en español del informe, se ha perdido una frase que a mi me parece fundamental.
The design of the Ariane 5 SRI is practically the same as that of an SRI which is presently used on Ariane 4, particularly as regards the software.
Es decir, que el software del Ariane-5 es una copia exacta del software del Ariane-4. Fue una forma de reducir costes. Más abajo encontramos este párrafo:
Los requerimientos originales que se tienen en cuenta para la operación continuada del software de alineamiento después del despegue fueron llevados a cabo después de hace más de 10 años para los modelos tempranos de Ariane, con el objetivo de manejar el improbable suceso de una suspensión de la cuenta atrás, entre -9 segundos, cuando el modo de vuelo empieza en el SRI de Ariane 4, y -5 segundos, cuando ciertos sucesos son iniciados en la lanzadera, los cuales llevan varias horas de reinicialización. El periodo seleccionado para esta operación de alineamiento continuada, 50 segundos después del comienzo del modo de vuelo, estaba basado en el tiempo necesario para que en equipo de tierra retomara el pleno control de la lanzadera en el caso de suspensión.
Esta especial prestación hacía posible con las versiones anteriores de Ariane el recomenzar la cuenta atrás sin esperar al alineamiento normal, lo cual lleva 45 minutos o más, por lo que la corta ventana de lanzamiento podía aún ser usada. De hecho, esta prestación fue usada una vez, en 1989 en el vuelo 33.
El mismo requisito no se aplica a Ariane-5, el cual tiene una secuencia de preparación diferente y fue mantenido por razones de uniformidad, presumiblemente basadas en la hipótesis de que, a menos de que se probara su necesidad, no era preciso hacer cambios en el software que funcionaba bien en Ariane-4.
Es decir, estaban utilizando el software del Ariane-4, basado en unas especificaciones de hacía 10 años, en una plataforma totalmente distinta y con una secuencia de lanzamiento diferente. Es decir, los ingenieros de software del Ariane-4 hicieron bien su trabajo. Lo que nadie les dijo, es que su mismo programa iba a ser utilizado en el Ariane-5, con unas condiciones totalmente distintas, por motivos político-económicos. Todos los precálculos que habían hecho fueron inútiles. Y, por ahorrar costes, nadie se molestó en repetirlos.
Mucha gente se empeña en decir que este fue el primer caso de un bug informático grave. Como hemos visto, el programa seguía las especificaciones impuestas. El problema es que cuando cambias las especificaciones, no puedes pedir que siga funcionando igual.
Es como un coche con un motor estupendo. Si le quitas los neumáticos, las llantas se romperán, el coche no andará y posiblemente acabes quemando el motor y la trasmisión. ¡Pero sería de locos echarle la culpa al motor de eso!
Más información:
http://en.wikipedia.org/wiki/Ariane_5
http://en.wikipedia.org/wiki/Ariane_5_Flight_501
http://www.upv.es/satelite/trabajos/pract_9/kike/paginas/accid.htm
http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
Actualización: Por supuesto, Omalaled lo cuenta muy bien en su blog. A pesar de que es un blog que sigo casi a diario, había olvidado que él había hecho esa entrada.
También en Youtube se puede encontrar el vídeo de la explosión.
Automatic Human Behavior 