Documentos de Académico
Documentos de Profesional
Documentos de Cultura
ARIANE-5
Prof. J. L. LIONS
INTRODUCCIN
El 4 de Junio de 1996, el vuelo inaugural de la lanzadera Ariane-5 result fallido. Tan
slo 40 segundos aproximadamente despus de la iniciacin de la secuencia de vuelo, a
una altitud de aproximadamente 3700 m, la lanzadera se desvi de su ruta, se parti y
explot. Los ingenieros de los equipos del proyecto Ariane-5 de CNES & Industry
empezaron inmediatamente a investigar el fallo. En los das siguientes, el Director
General de la ESA y el Presidente de la CNES formaron una Comisin de Investigacin
independiente y nombraron a los siguientes miembros:
Hemos (la Comisin) trabajado exhaustivamente para presentar una explicacin muy
precisa de las razones del fallo y para contribuir a la mejora del software del Ariane-5.
Esta mejora es necesaria para asegurar el xito del programa.
El Presidente de la Comisin.
1. EL FALLO
1.1 DESCRIPCIN GENERAL
El origen del fallo fue por tanto rpidamente localizado en el sistema de control de
vuelo y ms particularmente en los Sistemas de Referencia Inercial, que obviamente
dejaron de funcionar casi simultneamente sobre aproximadamente H0+36.7 segundos.
A pesar de esto, fue posible recuperar de los fragmentos los dos Sistemas de Referencia
Inercial. De particular inters fue aquel que funcion en modo activo y dej de
funcionar el ltimo, y para el cual, adems, cierta informacin no estaba disponible en
los datos telemtricos (la informacin transmitida a tierra no dejaba claro cul de las dos
unidades haba fallado primero). Los resultados del exmen de esta unidad fueron de
gran ayuda para el anlisis de la secuencia de fallos.
Hay algunas explicaciones preliminares como posibles causas de estas variaciones, las
cuales estn ahora bajo investigacin.
Basndose en la extensa documentacin y datos del fallo del Ariane 501 puestos a
disposicin de la Comisin, se han establecido la siguiente cadena de acontecimientos,
sus interrelaciones y sus causas, comenzando con la destruccin de la lanzadera y
rastreando atrs en el tiempo hacia la causa primaria.
Los acontecimientos internos del SRI que llevaron al fallo han sido reproducidos por
clculos de simulacin. Adems, ambos SRIs fueron recuperados durante la
investigacin de la Comisin y el contexto del fallo fue precisamente determinado a
partir de las lecturas de las memorias. En adicin, la Comisin ha examinado el cdigo
del software el cual demostr ser consistente con el escenario del fallo. Los resultados
de estos exmenes estn documentados en el Informe Tcnico.
En el escenario del fallo, las causas tcnicas primarias son el Error de Operando al
convertir la variable BH, y la falta de proteccin de esta conversin, lo que caus la
parada de la computadora del SRI.
La razn para que esas tres variables restantes, incluyendo la que denotaba la velocidad
horizontal, estuvieran desprotegidas fue que o bien estaban fsicamente limitadas o bien
estaban en un gran margen de seguridad, un razonamiento que en el caso de la variable
BH se demostr errneo. Es importante hacer notar que la decisin de proteger ciertas
variables pero no otras fue tomada consensuadamente entre los socios del proyecto a
varios niveles contractuales
No hay evidencia de que ningn dato de trayectoria haya sido usado para analizar el
comportamiento de las variables no protegidas, y es an ms importante hacer notar que
fue consensuado el no incluir los datos de trayectoria de Ariane-5 en los requerimientos
del SRI y las especificaciones.
Aunque la fuente del Error de Operando ha sido identificada, esto en s mismo no caus
el fallo de la misin. La especificacin del mecanismo de manejo de excepciones
tambin contribuy al fallo. En el caso de cualquier clase de excepcin, la
especificacin del sistema indicaba que: el fallo deba ser indicado en el bus de datos, el
contexto del fallo debera ser almacenado en una memoria EEPROM (que fue
recuperada y leda en Araine 501), y finalmente, el procesador del SRI debera ser
apagado.
Los requerimientos originales que se tienen en cuenta para la operacin continuada del
software de alineamiento despus del despegue fueron llevados a cabo despus de hace
ms de 10 aos para los modelos tempranos de Ariane, con el objetivo de manejar el
improbable suceso de una suspensin de la cuenta atrs, 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 reinicializacin. El
periodo seleccionado para esta operacin de alineamiento continuada, 50 segundos
despus 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 suspensin.
Esta especial prestacin haca posible con las versiones anteriores de Ariane el
recomenzar la cuenta atrs sin esperar al alineamiento normal, lo cual lleva 45 minutos
o ms, por lo que la corta ventana de lanzamiento poda an ser usada. De hecho, esta
prestacin fue usada una vez, en 1989 en el vuelo 33.
Esto significa que el software crtico - en el sentido de que el fallo de dicho software
pone en peligro la misin - debera ser identificado a un nivel muy detallado, ese
comportamiento excepcional debe ser aislado, y una poltica razonable de recuperacin
debe tener en cuenta fallos software.
Cualificacin de equipos
Cualificacin de software (software del Computador de a Bordo)
Integracin de etapa
Pruebas de validacin del Sistema.
La lgica aplicada es probar a cada nivel lo que no se pudo conseguir en el nivel previo,
por lo tanto se provee una cobertura completa de las pruebas de cada subsistema y del
sistema integrado.
Las pruebas a nivel de equipos fueron en el caso del SRI conducidas rigurosamente con
respecto a todos los factores medioambientales y de hecho mas all de lo que se
esperaba para Ariane-5. Sin embargo, no se realiz ningn test para verificar que el SRI
se comportara correctamente cuando estuviera sujeto a las secuencias de cuenta atrs,
de vuelo y de trayectoria de Ariane-5.
Es notable que por razones fsicas, no es factible probar el SRI como "caja negra" en el
medio ambiente de vuelo, a menos que uno haga una prueba de vuelo totalmente
realista, pero es posible hacer pruebas en tierra inyectando seales aceleromtricas
simuladas de acuerdo con los parmetros de vuelo previstos, mientras se usa tambin
una tabla de giros para simular los movimientos angulares de la lanzadera. Si se hubiese
llevado a cabo una prueba as por parte del suministrador o como parte del test de
aceptacin, el mecanismo de fallo habra sido puesto de relieve.
La trayectoria nominal
Trayectorias degradadas con respecto a parmetros internos de la lanzadera
Trayectorias degradadas con respecto a parmetros atmosfricos
Fallos de equipos y el subsiguiente aislamiento del fallo y recuperacin.
No es obligatorio, aunque s recomendable, que todas las partes del subsistema estn
presentes en todos los tests a un nivel dado. A veces esto no es fsicamente posible o no
es posible probarlos completamente o de forma representativa. En estos casos es lgico
reemplazarlos con simuladores pero solamente despus de cerciorarse cuidadosamente
de que los tests de niveles anteriores han cubierto todos los campos enteramente.
Este procedimiento es especialmente importante para el test final del sistema antes de
que sea usado operacinalmente (los tests realizados en la lanzadera 501 no se
mencionan porque no son especficos de la cualificacin del Sistema Elctrico de
Control de Vuelo).
Con el objetivo de entender las explicaciones dadas sobre la decisin de no tener los dos
SRIs en la simulacin en bucle cerrado, es necesario describir las configuraciones de
prueba que se podran haber usado.
Como no es posible simular las grandes aceleraciones lineales de la lanzadera en los tres
ejes sobre una plataforma de prueba (como se ha mencionado ms arriba). hay dos
maneras de colocar el SRI en el bucle:
Ponerlo en una plataforma dinmica de tres ejes (para estimular los Giroscopios
Lser en Anillo) y sustituir la salida analgica de los acelermetros (que no
pueden ser estimulados mecnicamente) mediante una simulacin por medio de
un conector de entrada de prueba dedicado y una tabla electrnica diseada para
este propsito. Esto es similar al mtodo mencionado en conexin con las
pruebas posibles a nivel de equipamiento.
Sustituir ambos, la salida analgica de los acelermetros y los Giroscopios Lsre
en Anillo por medio de un conector de entrada de prueba dedicado con seales
producidas por la simulacin.
Cuando la filosofa del test del proyecto fue definida, la importancia de tener los SRIs
en el bucle se tuvo en cuenta y se tom la decisin de seleccionar el segundo mtodo.
En una etapa posterior del programa (en 1992), esta decisin se cambi. Se decidi no
tener los SRIs reales en el bucle por las siguientes razones:
Mientras que es deseable una alta precisin en la simulacin, en los tests del sistema en
el ISF es claramente mejor un compromiso en cuanto a precisin pero conseguir todos
los dems objetivos, entre ellos probar la correcta integracin en el sistema de equipos
como el SRI. La precisin del sistema de gua puede ser efectivamente demostrada por
anlisis y simulacin por ordenador.
Bajo esta cabecera se debera hacer notar finalmente que los consiguentes medios de
prevenir fallos son las revisiones, las cuales son una parte integral del proceso de diseo
y cualificacin, a las cuales son llevadas a cabo a todos los niveles e incluyen a todos
los socios mayoritarios del proyecto (as como socios externos). En un programa de este
tamao, literalmente miles de problemas y fallos potenciales son manejados con xito
en el proceso de revisin y obviamente no es fcil detectar errores de diseo de software
del tipo del que fue la causa tcnica principal del fallo de Ariane 501. De todas formas,
es evidente que las limitaciones del software del SRI no fue analizado plenamente en las
revisiones, y no se tuvo en cuenta que la cobertura del test era inadecuada al exponerse
a tales limitaciones. Ni lo fueron las posibles implicaciones de permitir que el software
de alineamiento operara durante el vuelo. A estos respectos, el proceso de revisin fue
un factor que contribuy al fallo.
3. CONCLUSIONES
3.1 RESULTADOS
El fallo de Ariane 501 fue causado por la completa prdida de gua e informacin de
orientacin 37 segundos despus del comienzo de la secuencia de ignicin del motor
principal (30 segundos despus del despegue). Esta prdida de informacin fue debida a
errores de especificacin y diseo en el software del sistema de referencia inercial.Las
extensas revisiones y tests llevados a cabo durante el programa de desarrollo del Ariane-
5 no incluy el adecuado anlisis y prueba del sistema de referencia inercial o del
sistema de control de vuelo completo, lo cual podra haber detectado los fallos
potenciales.
4. RECOMENDACIONES
Sobre la base de sus anlisis y conclusiones, la Comisin hace las siguientes
recomendaciones: