ASTRONAUTICA Y ASTROFILATELIA

Cualificación de software (software del Computador de a Bordo) .

Integración de etapa .
Pruebas de validación del Sistema.
La lógica 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ó ningún test para verificar que el SRI se comportaría correctamente cuando estuviera sujeto a las secuencias de cuenta atrás, de vuelo y de trayectoria de Ariane-5.
Es notable que por razones físicas, 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 señales acelerométricas simuladas de acuerdo con los parámetros de vuelo previstos, mientras se usa también 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 aceptación, el mecanismo de fallo habría sido puesto de relieve.
La explicación principal para la ausencia de dicho test ya se ha mencionado anteriormente, pues la especificación del SRI (que se supone un documento de requisitos del SRI) no contiene los datos de trayectoria de Ariane-5 como requisito funcional.
La Comisión se ha percatado de que la especificación de los sistemas del SRI no indica las restricciones operacionales que surgen de la implementación elegida. Tal declaración de limitaciones, que debería ser obligatoria para cada dispositivo crítico para la misión, habría servido para identificar cualquier falta de cumplimiento con la trayectoria de Ariane-5.
La otra oportunidad principal de detectar el mecanismo de fallo de antemano fue durante los numerosos tests y simulaciones llevados a cabo en la Instalación de Simulación Funcional, ISF, que se encuentra en el emplazamiento del Arquitecto Industrial. El objetivo de los tests del ISF son cualificar:

La realización de la guía, la navegación y el control en el paquete entero de vuelo,
La operación de redundancia de sensores, - las funciones dedicadas de las etapas,
El software de vuelo (Computador de a Bordo) y su cumplimiento con todos los equipos del Sistema Eléctrico de Control de Vuelo.

Se realizaron un gran número de simulaciones en bucle cerrado del vuelo completo simulando la operación del segmento de tierra, el flujo telemétrico y la dinámica de la lanzadera, con el objetivo de verificar:

La trayectoria nominal.
Trayectorias degradadas con respecto a parámetros internos de la lanzadera.
Trayectorias degradadas con respecto a parámetros atmosféricos.
Fallos de equipos y el subsiguiente aislamiento del fallo y recuperación.

En estas pruebas muchos puntos del equipamiento estaban físicamente presentes y en ejercicio, pero no los dos SRIs, los cuales fueron simulados por módulos software específicamente diseñados. Algunos tests en bucle abierto, para verificar el cumplimiento con el OBC y el SRI, fueron realizados con el SRI real. Se entiende que fueron simples tests de integración eléctrica y tests de cumplimiento a "bajo nivel" (bus de comunicación).
No es obligatorio, aunque sí recomendable, que todas las partes del subsistema estén presentes en todos los tests a un nivel dado. A veces esto no es físicamente posible o no es posible probarlos completamente o de forma representativa. En estos casos es lógico reemplazarlos con simuladores pero solamente después 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 específicos de la cualificación del Sistema Eléctrico de Control de Vuelo).
Con el objetivo de entender las explicaciones dadas sobre la decisión de no tener los dos SRIs en la simulación en bucle cerrado, es necesario describir las configuraciones de prueba que se podrían 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 más arriba). hay dos maneras de colocar el SRI en el bucle:

Ponerlo en una plataforma dinámica de tres ejes (para estimular los Giroscopios Láser en Anillo) y sustituir la salida analógica de los acelerómetros (que no pueden ser estimulados mecánicamente) mediante una simulación por medio de un conector de entrada de prueba dedicado y una tabla electrónica diseñada para este propósito. Esto es similar al método mencionado en conexión con las pruebas posibles a nivel de equipamiento.
Sustituir ambos, la salida analógica de los acelerómetros y los Giroscopios Lásre en Anillo por medio de un conector de entrada de prueba dedicado con señales producidas por la simulación.
La primera aproximación es parecida a proveer de una simulación precisa (dentro de los límites del ancho de banda de la tabla dinámica de tres ejes) y es bastante cara; la segunda es más barata y su rendimiento depende esencialmente de la precisión de la simulación. En ambos casos una gran parte de la electrónica y del software completo se prueba en el medio ambiente operacional real.

Cuando la filosofía del test del proyecto fue definida, la importancia de tener los SRIs en el bucle se tuvo en cuenta y se tomó la decisión de seleccionar el segundo método. En una etapa posterior del programa (en 1992), esta decisión se cambió. Se decidió no tener los SRIs reales en el bucle por las siguientes razones:
Los SRIs debían considerarse plenamente cualificados a nivel de equipamiento La precisión del software de navegación en el OBC depende críticamente de la precisión en las medidas del SRI. En el ISF, esta precisión no se podía conseguir mediante aparatos electrónicos que crearan las señales de prueba. La simulación de los modos de error no es posible con equipos reales, sino solamente con modelos.
El periodo base del SRI es de 1 milisegundo mientras que el de la simulación en el ISF es de 6 milisegundos. Esto se añade a la complejidad del interface electrónico y podía incluso reducir la precisión de la simulación.
La opinión de la Comisión es que estos argumentos eran válidos técnicamente, pero como el propósito de una prueba de simulación del sistema no es solamente verificar los interfaces sino también verificar el sistema como un todo para una aplicación particular, existía un riesgo al asumir que el equipo crítico tal como el SRI había sido validado por sí mismo, o por uso previo con Ariane-4.
Mientras que es deseable una alta precisión en la simulación, en los tests del sistema en el ISF es claramente mejor un compromiso en cuanto a precisión pero conseguir todos los demás objetivos, entre ellos probar la correcta integración en el sistema de equipos como el SRI. La precisión del sistema de guía puede ser efectivamente demostrada por análisis y simulación por ordenador.
Bajo esta cabecera se debería hacer notar finalmente que los consiguentes medios de prevenir fallos son las revisiones, las cuales son una parte integral del proceso de diseño y cualificación, 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 tamaño, literalmente miles de problemas y fallos potenciales son manejados con éxito en el proceso de revisión y obviamente no es fácil detectar errores de diseño de software del tipo del que fue la causa técnica 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 revisión fue un factor que contribuyó al fallo.

2.4 OTRAS POSIBLES DEBILIDADES DEL SISTEMA IMPLICADAS.
De acuedo con sus competencias, la Comisión ha examinado otras posibles debilidades, principalmente en el Sistema de Control de Vuelo. No se encontraron debilidades relacionadas con el fallo, pero a pesar del corto tiempo disponible, la Comisión ha dirigido una extensa revisión del Sistema de Control de Vuelo basada en la experiencia ganada durante el análisis del fallo.
La revisión ha cubierto las siguientes áreas:
El diseño del sistema eléctrico, Software implementado a bordo en susbsistemas además del Sistema de Referencia Inercial, El OBC y el software del programa de vuelo.
Además, la Comisión ha hecho un análisis de los métodos aplicados en el programa de desarrollo, en particular con respecto a la metodología de desarrollo del software.
Los resultados de estos esfuerzos se han documentado en el Informe Técnico y la Comisión espera que contribuirán a mejoras del Sistema de Control de Vuelo del Ariane-5 y su software.

3. CONCLUSIONES.
3.1 RESULTADOS.
La Comisión ha alcanzado las siguientes conclusiones:
Durante la campaña de preparación del lanzamiento y la cuenta atrás no ocurrieron sucesos relacionados con el fallo Las condiciones meteorológicas a la hora del lanzamiento eran aceptables y no jugaron ningún papel en el fallo. Ningún otro factor externo de relevancia ha sido encontrado.
La ignición del motor y el despegue fueron esencialmente nominales y los efectos medioambientales (ruido y vibración) de la lanzadera y la carga útil no se encontraron relevantes para el fallo. El rendimiento de la propulsión estaba dentro de especificaciones.
22 segundos después de H0 (comando de ignición del motor principal criogénico), empezaron a aparecer variaciones de frecuencia 10 Hz en la presión hidráulica de los actuadores que controlan la boca del motor principal. Este fenómeno es significativo y no ha sido explicado plenamente, pero después de considerarlo no ha sido encontrado relevante para el fallo.
A los 36.7 segundos después de H0 (aproximadamente 30 segundos después del despegue) la computadora del sistema de referencia inercial de reserva, que trabajaba en stand-by para la guía y el control de orientación, perdió su operatividad. Esto fue causado por una variable interna relacionada con la velocidad horizontal de la lanzadera, que excedió el límite existente en el software del computador.
Aproximadamente 0.05 segundos después el sistema de referencia inercial activo, idéntico al de reserva en hardware y software, falló por la misma razón. Como el sistema inercial de reserva ya no era operativo, la información correcta de guía y orientación no se pudo obtener más y la pérdida de la misión fue inevitable.
Como resultado de su fallo, el sistema de referencia inercial activo transmitió esencialmente información de diagnóstico a la computadora principal de la lanzadera, que fue interpretada como información de vuelo y usada para cálculos de control de vuelo.
Sobre la base de estos cálculos la computadora principal ordenó a las bocas de los propulsores, y algo después a la boca del motor principal también, que hicieran una enorme corrección para una desviación de orientación que no había ocurrido.
Ocurrió un rápido cambio de orientación lo cual causó que la lanzadera se desintegrara a los 39 segundos después de H0 debido a fuerzas aerodinámicas.
La destrucción fue automáticamente iniciada sobre la desintegración, como estaba diseñado, a una altitud de 4 Km y una distancia de 1 Km de la plataforma de lanzamiento.
Los fragmentos se esparcieron sobre un área de 5 x 2.5 Km2. Entre el equipo recuperado estaban los dos sistemas de referencia inerciales. Han sido usados para el análisis.
El análisis post-vuelo de los datos de telemetría han listado cierto número de anomalías adicionales que están siendo investigadas pero no han sido consideradas significativas para el fallo.
El sistema de referencia inercial de Ariane-5 es esencialmente común a un sistema que actualmente está volando en Ariane-4. La parte de este software que causó la interrupción en los computadores del sistema inercial se usa antes del lanzamiento para alinear el sistema de referencia inercial y, en Ariane-4, también para habilitar un rápido realineamiento del sistema en caso de una suspensión tardía de la cuenta atrás. Esta función de realineamiento, que no sirve para nada en el Ariane-5, fue aún así retenida por razones de comunalidad y permitida, como en Ariane-4, su operación durante aproximadamente 40 segundos después del despegue.
Durante el diseño del software del sistema de referencia inercial usado para Ariane-4 y Ariane-5, se tomó la decisión de que no era necesario proteger la computadora del sistema inercial de perder su operatividad por un valor excesivo de la variable relacionada con la velocidad horizontal, una protección de que habían sido provistas otras variables del software de alineamiento. Cuando se tomó esta decisión, no fueron analizados o plenamente comprendidos los valores que esta variable en particular podía asumir cuando el software de alineamiento operara tras el despegue.
En los vuelos de Ariane-4 usando el mismo tipo de sistema de referencia inercial no ha habido tal fallo porque la trayectoria durante los primeros 40 segundos de vuelo es tal que la variable particular relacionada con la velocidad horizontal no puede alcanzar, con un adecuado margen operacional, un valor más allá del límite presente en el software. Ariane-5 tiene una aceleración inicial alta y una trayectoria que lleva a una elevación del valor de la velocidad horizontal que es cinco veces más rápida que en Ariane-4. El valor más alto de velocidad horizontal generado para Ariane-5, dentro del marco de tiempo de 40 segundos, causó un valor excesivo que provocó que cesara la operación de los computadores del sistema inercial.
El propósito del proceso de revisión, que incluye a todos los socios mayoritarios del programa Ariane-5, es validar decisiones de diseño y obtener cualificación de vuelo. En este proceso, las limitaciones del software de alineamiento no fueron plenamente analizadas y las posibles implicaciones de permitir su función durante en vuelo no se tuvieron en cuenta.
La especificación del sistema de referencia inercial y los tests realizados a nivel de equipamiento no incluyeron específicamente los datos de trayectoria de Ariane-5. Consecuentemente la función de realineamiento no fue probada bajo condiciones de vuelo simuladas de Araine-5, y el error de diseño no fue descubierto.
Hubiera sido técnicamente factible incluir casi el sistema de referencia inercial entero en las simulaciones globales que se realizaron. Por ciertas razones se decidió usar la salida simulada del sistema de referencia inercial, no el sistema propiamente dicho o su simulación detallada. Si el sistema hubiera sido incluido, el fallo se hubiese podido detectar. Las simulaciones post-vuelo se han llevado a cabo en un computador con software del sistema de referencia inercial y con un medio ambiente simulado, incluyendo los datos de la trayectoria real del vuelo Ariane 501. Estas simulaciones han reproducido fielmente la cadena de acontecimientos que llevaron al fallo de los sistemas de referencia inercial.

3.2 CAUSA DEL FALLO.
El fallo de Ariane 501 fue causado por la completa pérdida de guía e información de orientación 37 segundos después del comienzo de la secuencia de ignición del motor principal (30 segundos después del despegue). Esta pérdida de información fue debida a errores de especificación y diseño 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 análisis y prueba del sistema de referencia inercial o del sistema de control de vuelo completo, lo cual podría haber detectado los fallos potenciales.

4. RECOMENDACIONES.
Sobre la base de sus análisis y conclusiones, la Comisión hace las siguientes recomendaciones:
Desconexión de la función de alineamiento del sistema de referencia inercial inmediatamente después del despegue. Más generalmente, ninguna función software debería ser ejecutada durante el vuelo salvo necesidad.
Preparar una instalación de prueba que incluya tanto equipamiento real como sea factible técnicamente, inyectar datos de entrada reales, y realizar un test del sistema completo en bucle cerrado. Las simulaciones completas deben tener lugar antes de cualquier misión. Una gran cobertura de test debe ser obtenida.
No permitir que ningún sensor, como el sistema de referencia inercial, pare de enviar datos lo mejor posibles. Organizar, para cada unidad de equipamiento que incorpore software, una revisión de cualificación de software específica. El Arquitecto Industrial deberá tomar parte en estas revisiones e informar del test del sistema completo realizado con el equipo. Todas las restricciones en el uso del equipamiento deberán estar explícitas para la Comisión de Revisión. Hacer todo el software crítico un Asunto Controlado de Configuración (CCI).
Revisar todo el software de vuelo (incluyendo software implementado) y en particular:
Identificar todas las asunciones implícitas hechas por el código y sus documentos de justificación sobre los valores de cantidades provistas por el equipamiento. Probar estas asunciones contra las restricciones en el uso del equipamiento.
Verificar el rango de valores tomados por cualquier variable interna o de comunicación en el software. Soluciones a problemas potenciales en el software del OBC, prestando particular atención sobre la conmutación de OBC, debería ser propuesta por el equipo del proyecto y revisada por un grupo de expertos externos, que deberán informar a la Comisión de Cualificación del OBC. Donde sea técnicamente factible, considerar el aislamiento de excepciones a tareas y proveer de capacidad de recuperación.
Proveer de más datos a la telemetría sobre el fallo de cualquier componente, para que la recuperación del equipo sea menos esencial.
Reconsiderar la definición de componentes críticos, tomando en cuenta fallos de origen software (particularmente fallos en puntos simples). Incluir participantes externos (al proyecto) cuando se revisen las especificaciones, código y documentos de justificación. Asegurarse de que estas revisiones consideran la esencia de los argumentos, además de probar que se han realizado las verificaciones.
Incluir los datos de trayectoria en las especificaciones y los requisitos de las pruebas.
Revisar la cobertura de las pruebas del equipamiento existente y extenderla hasta donde se estime necesario. Darle a los documentos de justificación las mismas atenciones que al código. Mejorar la técnica de mantenimiento de la consistencia del código y sus justificaciones.
Crear un equipo que preparará el procedimiento para cualificar el software, propondrá reglas estrictas para confirmar dicha cualificación, y cerificará que especificación, verificación y test del software son de una alta y consistente calida en el programa Ariane-5. Se considerará la inclusión de expertos RAMS externos.
Una organización más transparente de la cooperación entre los socios en el programa Ariane-5 debería ser considerada. La cooperación cercana en ingeniería, con autoridad y responsabilidad claramente delimitadas, es necesaria para conseguir la coherencia del sistema, con interfaces claros y simples entre socios.