EDICIóN GENERAL
129 meneos
2522 clics
Un error en una cifra provocó el incidente de la misión VA241 del Ariane 5

Un error en una cifra provocó el incidente de la misión VA241 del Ariane 5

No sería hasta 9 minutos y 26 segundos tras el despegue cuando se percataron de que algo iba mal. En ese momento el cohete, volando más al sur de lo planeado, quedó fuera del alcance de las estaciones de tierra situadas en África y se perdió la telemetría del vehículo. La telemetría no se volvería a recibir hasta que los dos satélites ya estaban situados en órbita, aunque para entonces los encargados de la misión pensaban que el lanzamiento había sido un fracaso e incluso llegaron a disculparse públicamente por el error.

| etiquetas: va241 , ariane 5 , error , astronáutica
Y digo yo... ¿No han probado antes los datos finales que introducirán en un simulador? Para pagar toda Europa estas cosas, igual no están haciendo muy bien el trabajo...
#2 Hasta puede que si, pero es basta te dificil que se equivocasen tambien al meter los datos en el simulador, y si esto pasase seguramente volverían a repetir la simulacion con los datos correctos, y todo esto no imposibilita que alguien se equivoque después al meter los datos en el sistema real.
Un articulo muy interesante. Todavia estamos lejos de tener una fiabilidad absoluta en el sector espacial. La complejidad de los sistemas es enorme y por muchos procesos que haya en pie siempre hay cierto factor humano que puede poner en peligro las misiones.

Tambien tenemos que pensar que aunque se hagan muchos lanzamientos, esto no es como volar un avion... es mucho menos frecuente y todavia hay mucho refinamiento en marcha.
#3 La fiabilidad de los sistemas en el CSG debe ser de un mínimo del 97% y esto se comprueba dos días antes en el ensayo general que se realiza antes de cada lanzamiento, si no se alcanza este valor significa un rojo y no se lanza. El factor humano se controla mediante el doble check de parámetros en los puntos críticos de control de cada proceso por lo que aquí ha metido la pata el que ha introducido el valor y el que lo ha validado.
#10 El doble check de parametros y la '4 eyes rule' disminuye la probabilidad de errores, pero como hemos visto no la elimina. A estas dos personas se les caera el pelo, pero seguramente no sea su culpa: me gustaria saber con que interfaz trabajan, la cantidad de cambios que implicaba ese cambio de inclinacion y si habia algun tipo de 'consistency check' en el programa o la simulacion, que tipos de reportes se generan, etc.

Si hubiera sido trivial ver el error, lo hubieran visto. Y mira que luego en 'real time' tampoco se dieron cuenta de que nada fuera mal hasta que se perdio la telemetria.... algo me dice que las simulaciones fueron correctas, pero tampoco se veia nada raro.
#11 Si en el ensayo general se trabajó con parámetros correctos no se podía detectar ese error de forma sistemática el día del lanzamiento. Al final un lanzamiento tiene mucho de artesanal o manual, por ejemplo: el sistema de anulación de la lanzadera actua de forma manual y solo automaticamente si la lanzadera se sale de la ventana de trayectoria. Los datos y reportes que comentas los conozco como exingeniero RAMS en el CSG pero evidentemente son confidenciales.
Resumiendo, la culpa fue del informático. :troll:
#4 Del informático no. Error del usuario, el que introduce los datos no tiene porqué ser informático y en realidad no lo suele ser en la mayoría de los casos.
#4 Y eso que le dijeron que cuando el informático terminara de instalar el programa, tenía que ejecutarlo.
#6 ¿al informático? xD
ERROR HUMANO, OIGAN
comentarios cerrados

menéame