miércoles, diciembre 10, 2008

El fallo informático más gordo

El Ariane-5 era algo más que la continuación de los anteriores. El diseño prácticamente era nuevo. La nueva lanzadera tiene dos secciones. La de abajo es la parte común para todas las misiones y la superior depende de la carga que se va a poner en órbita.

Las dimensiones, los motores, la fuerza de empuje, son datos impresionantes.

El 4 de junio de 1996, en su primer vuelo, la expectación fue enorme. Todo el mundo estaba observando. Despegó y a los 40 segundos, empieza a girar sobre si mismo hasta que explota.


A los pocos días se nombró una comisión de investigación formada por técnicos de diferentes países. Y esto fue lo que encontraron:

Datos de vuelo:

Hasta el segundo 42 tenían datos telemétricos remitidos a tierra, señales de radar e imágenes visuales.

1-Antes del despegue, todo normal.
2-Despegue, todo normal.
3-Hasta el segundo 36, todo normal.
4-Fallo del sistema de referencia inercial de reserva.
5-Fallo del sistema de referencia intercial activo.
6-La posición de las bocas de los propulsores y del motor van a la posición más extrema.
7-Autodestrucción de la lanzadera.

Con estos datos, ya vieron lo que falló: el sistema de referencia inercial.

Recogida de más datos:

La zona de despegue (Kourou, Guayana Francesa) estaba rodeada de árboles. La explosión fue sobre los 4.000 m. Los fragmentos se dispersaron a lo largo de 12 km cuadrados. Patearon toda la zona y encontraron los dos sistemas de referencia inerciales los cuales tenían datos valiosísimos que no se habían remitido a tierra. De esta forma se supo que primero falló el sistema de reserva y luego el principal.

El diseño

Lógicamente, lo primero que tenemos que saber es qué es eso del sistema de referencia inercial. Para decirlo con cuatro palabras. Parece un montón sensores (giroscopios láser y acelerómetros) conectados a un procesador. De esta forma se mide en todo momento el movimiento, orientación, velocidad, aceleración de la lanzadera.

Este sistema de referencia inercial provee de datos a la computadora de a bordo (sí, como los coches de ahora) a través de un bus de datos.

Esa computadora central tiene el programa de vuelo y va accionando las bocas de los propulsores, el motor, etc. por medio de elementos hidráulicos.

El hecho de que hubiera dos sistemas de referencia inerciales era para evitar el desastre en caso de que fallara el principal. El hardware y el software eran iguales. Como se suele decir ahora eran un activo pasivo y encargado de "switchear" es el computador de a bordo en caso de detectar algún fallo.

El computador de a bordo también estaba duplicado.

El fallo

La secuencia "marcha atrás" fue la siguiente:

  • A la velocidad que va el cohete y con una inclinación del 20 grados (y subiendo), los propulsores se separan. Eso hace que se active la autodestrucción.
  • Ese giro no planeado se produce porque las bocas de los propulsores y del motor se encuentran "a tope".
  • Estaban "a tope" porque así lo había ordenado la computadora de a bordo.
  • Los datos que cogió de referencia la computadora de a bordo eran los del sistema de referencia principal. No eran datos "buenos" pero los tomó como si lo fueran.
  • El sistema de referencia principal no enviaba datos "buenos" porque se había producido una excepción en el software.
  • Aunque había una excepción, el ordenador de a bordo no cambió al sistema de referencia secundario porque este había fallado antes que el principal. En el secundario se había producido la misma excepción.
  • La excepción se produjo en una conversión de datos de coma flotante (64 bits) a entero con signo (16 bits). Resulta que el número en coma flotante que se intentaba convertir no cabía en los 16 bits del entero. La excepción era un "Error de Operando". El código era Ada, y en esta parte del programa se habían tenido en cuenta otro tipo de errores de conversión, pero no el "Error de Operando".
Ya vemos el cariz que esta tomando esto, pero la realidad supera siempre a la ficción y lo que viene es flipante...

El módulo en el que ocurre el error es para una función de alineamiento que sólo es necesaria antes del despegue. Después del despegue ya no sirve para nada.

O sea, todo se fue al garete sin necesidad. Se trataba de un código que no debería estar ejecutándose.

La cosa es algo más complicada que eso. El Ariane-4 si que necesitaba esa función durante 50 segundos desde la activación del "modo de vuelo" de los sistemas de referencia inerciales. Esos 50 segundos se terminan sobre el segundo 40 desde el despegue. El Ariane-5 no necesitaba esa función en vuelo.
  • El Error de operando se produjo porque la función se encontró con un valor más alto de lo esperado. La variable está relacionada con la velocidad horizontal de la plataforma.
  • Era más alto que lo normal porque la trayectoria del Ariane-5 es diferente del Ariane-4 y lo que no era normal en el anterior sí era normal en el nuevo cohete.
00:30 a.m.
Hora de dormir.
Mañana continuo, porque en el informe se intenta justificar el motivo por el cual no se hicieron todas las comprobaciones necesarias. Decían que no se quería llegar al 80% de la capacidad de proceso del sistema de referencia inercial, pero algo huele mal si realmente estaban ejecutando código innecesario.

Saludos.

Fuente: http://www.upv.es/satelite/trabajos/pract_9/kike/paginas/accid.htm

No hay comentarios: