QAbalgando por la historia (V): ¿Y si MTP hubiera trabajado en el Ariane 5 en 1996?

5 May, 2022

Testing de Software

Traemos hoy al Blog una nueva entrega de la serie de post que llamamos ‘QAbalgando por la historia’, en los que recordamos algunos proyectos fallidos en los que un aseguramiento de la Calidad de Software (QA) previo podría haber dado lugar a un resultado más satisfactorio. En el post de hoy, hacemos un ejercicio de ‘historia ficción’, a modo de ‘qué hubiera pasado si…’. Los protagonistas, dos profesionales de MTP y la historia del Ariane 5 de 1996.

[contact-form-7 id="22307" title="Formulario Blog"]

Dos empleados de MTP estaban frente una ventana grande, con vistas a la calle. Uno de ellos quiso compartir con su compañero una idea que se le vino a la cabeza.

– Aunque MTP no se fundó hasta 1997, ¿qué podría haber pasado si hubiéramos trabajado en el sistema de guiado del Ariane 5 en 1996? – dijo.

– No lo sé, ¿qué habría pasado? – preguntó el otro.

– El primer lanzamiento del cohete Ariane 5, como sabes, después de diez años de desarrollo, se fue a pique por un fallo informático, causando una gran pérdida económica de más de 500 millones de dólares. Y yo me pregunto, ¿y si nosotros hubiésemos solucionado ese error y el cohete hubiera podido despegar como estaba previsto?

– ¿Cómo?

-En un artículo que leí hace tiempo, los fabricantes del lanzador declararon que seguirían las recomendaciones de las agencias aeroespaciales que investigaron las causas del desastre y contratarían empresas externas para comprobación de sus sistemas de verificación y validación del software crítico. Si nosotros hubiéramos estado involucrados en la metodología de validación del Sistema de Referencia Inercial, cuyo colapso provocó el accidente, nada de esto hubiera ocurrido. Se habrían ahorrado mucho dinero.

– ¿Y crees que nosotros hubiéramos podido solucionarlo?

-En efecto, aunque realmente los métodos de control de software crítico evolucionaron mucho posiblemente a consecuencia de este suceso. Veras, te lo explicaré. En las noticias dijeron que el software de guiado SRI se había usado sin problemas en su predecesor, el Ariane 4. Pero el Ariane 5 tenía mucha más aceleración y manejaba muchas más variables que desbordaron la potencia del calculador; un número real de 64 bits (también conocido como float) relacionado con la velocidad horizontal del cohete se convirtió en un entero de 16 bits. El programa enloqueció y transmitió informaciones erróneas que trataron de corregir una desviación inexistente. El cohete se desvió de su trayectoria y se autodestruyó a los 38 segundos de su lanzamiento. Los restos se esparcieron alrededor de la base espacial de Kourou, en la Guayana Francesa.

– ¿Y cómo lo hubiéramos arreglado?

-Sencillo, participando desde un principio. Por algo MTP se creó como una empresa de Aseguramiento de Calidad del Software. La investigación descubrió dos fallos fundamentales. El primero de ellos fue utilizar una simulación de resultados del SRI durante las pruebas, y no uno verdadero. La visión de Aseguramiento de la Calidad habría exigido estándares y directrices que impidieran utilizar simulaciones en software crítico. Además, los ingenieros del sistema de guiado y control dieron por supuesto que el software del SRI estaba suficientemente validado porque había pasado muchos ciclos de prueba dinámica operando en el Ariane 4, y en aquellos tiempos posiblemente no pudieron, o no supieron, hacer mucho en términos del análisis estático del código. Ya sabes, desbordamientos, divisiones por cero, accesos fuera de los límites de un array y otros errores de ejecución del código fuente.

– ¿Nosotros podríamos hacer todo eso? – preguntó sorprendido su compañero.

-Claro, en lo que respecta a la parte informática, somos MTP. Nosotros habríamos utilizado herramientas de análisis estático basado en patrones y conjuntos de reglas para detectar sintaxis de código asociadas a problemas sutiles que luego pueden concatenarse dando lugar a fallos catastróficos. También análisis de flujo para detectar errores de referencia de puntero, desbordamientos de buffer o contaminación de datos. Y con eso, nos hubiéramos ahorrado mucho dinero, ¿no te parece? -puso una sonrisa al final de la frase. – Como dijo la comisión que investigó aquel suceso: Se da por seguro que el sistema funciona bien hasta que se detecta un error, cuando, debía ser, al contrario, que funciona mal hasta que se comprueba que lo haga correctamente”.

El otro asintió con la cabeza. Ambos trabajadores miraron al cielo, atisbando un pequeño destello que terminó iluminado el cielo. Reflexión de uno de los empleados: “Alguien se ha vuelto a olvidar de llamarnos…”

 

Fernando Rosique

DBA Hub

 

Otros post de ‘QAbalgando por la historia’:

QAbalgando por la historia (I): Grace Murray Hopper

Qabalgando por la historia (II): Mars Climate Orbiter, el error de conversión que nos dejó sin fotos de Marte

QAbalgando por la historia (III): La destrucción del Mariner I (1962)

QAbalgando por la historia (IV): AT&T en 1990, el gran colapso de la red a larga distancia

Ver más historias