$ 500 millones por línea de código o el costo de los errores de software en el espacio
Hace un par de meses en edx.org, finalizó el curso "Introducción a la tecnología espacial: astronáutica y vuelos tripulados (Fin de la ingeniería aeroespacial: astronáutica y vuelo espacial humano)". El curso fue impartido por un astronauta estadounidense, actualmente profesor del MIT, Jeffrey Alan Hoffman. Como su nombre lo indica, el curso es bastante simple y general, sin embargo, me pareció bastante interesante e informativo.En una parte del curso, se aborda el tema de la seguridad y, entre otras cosas, estamos hablando de la seguridad del software. Profe. Hoffman proporciona ejemplos interesantes de problemas con el software para la aviación y la astronáutica. En este artículo, echaré un vistazo más de cerca a los ejemplos espaciales de las conferencias de Hoffmann.Marte aterrizador polar
Mars Polar Lander (MPL) Una nave espacial de 290 kilogramos lanzada por la NASA el 3 de enero de 1999 para estudiar el suelo y el clima alrededor del Polo Sur de Marte. El 3 de diciembre de 1999, durante el aterrizaje, el centro de control no pudo reanudar la comunicación con el dispositivo.
MPL en el Laboratorio de la NASACon soportes de aterrizaje abiertos y paneles solares, el MPL tenía 1.06 m de altura y tenía un tamaño transversal de 3.6 m. El cuerpo está hecho sobre la base de una estructura de aluminio en forma de panal sujeta con paneles de grafito-epoxi. Al aterrizar, se abren tres soportes de aluminio desde la posición de transporte y extinguen la energía de aterrizaje utilizando insertos de aluminio destructibles hechos en forma de panales.Curso de aterrizaje planificado
MPL ingresa a la atmósfera de Marte a una altitud de más de 100 km a una velocidad de ~ 7 km / s. En 3 minutos, el dispositivo desciende a una altitud de 8.8 km y se desacelera a una velocidad de 0.5 km / s, después de lo cual da una señal para abrir el paracaídas, que sigue inmediatamente después de que se separa el escudo térmico (escudo térmico). Cuando la velocidad del dispositivo se reduce a 85 m / s con un paracaídas, comienza a funcionar un radar que monitorea las características de la superficie para determinar el posible lugar de aterrizaje.
Diagrama de etapa de vuelo MPL1 minuto después de abrir el paracaídas a una altitud de 1.3 km, cuando la velocidad de descenso es de 80 m / s, el vehículo de descenso se separa de la carcasa exterior con un paracaídas (carcasa trasera) y comienza a aterrizar en los motores de freno. El tiempo de descenso esperado, con los motores en funcionamiento, es de aproximadamente 1 minuto, tiempo durante el cual el dispositivo disminuye a una altura de 12 m. Luego, los motores se apagan y el dispositivo realiza una caída planificada a la superficie. 5 minutos después de tocar la superficie, el dispositivo comienza a desplegar paneles solares y orientación de antena, lo que establecerá una conexión con la Tierra. Luego comienza la sesión de transferencia de datos, lo que indica que el aterrizaje fue exitoso.El curso de los acontecimientos
El 3 de diciembre, el módulo de aterrizaje fue desacoplado de la etapa de crucero y, hasta que se completó el aterrizaje, cambió al modo de silencio de radio planeado. A las 20:04:00 UTC, 6 minutos antes de ingresar a la atmósfera, la operación programada de los motores corrigió la posición del aparato, orientando la pantalla de calor. MPL entró en la atmósfera de Marte a una velocidad de 6.9 km / s a las 20:10:00 UTC. La reanudación de la comunicación se esperaba a las 20:39:00 UTC después del aterrizaje. Pero la conexión nunca se estableció y el dispositivo se declaró perdido.Se desconoce el motivo exacto de la pérdida de comunicación, pero el informe de investigación del accidente contiene la conclusión de que la causa más probable del accidente es un error de software que calculó incorrectamente las vibraciones durante la apertura de los soportes como vibración desde el aterrizaje. Como resultado, el dispositivo apagó los motores de freno a una altura de 40 m, a pesar del hecho de que se sabía que la divulgación de los soportes podría conducir a falsos positivos. Los términos de referencia para el software no prevén este caso.Cita del informe:“Los sensores magnéticos montados en cada uno de los tres soportes de aterrizaje sirven para determinar el momento de contacto con el suelo y apagar los motores de aterrizaje. Los datos obtenidos durante varias pruebas mostraron que en los sensores de aterrizaje (sensores Hall) se producen falsas alarmas durante la divulgación de los soportes (en este momento el dispositivo desciende en paracaídas). La lógica del programa recibe datos de los sensores como una señal de captación si se producen disparos en dos lecturas consecutivas. Las pruebas han demostrado que las señales a corto plazo que se producen cuando se abren los soportes son en realidad lo suficientemente largas como para causar un falso positivo. Casi siempre, uno de los tres pilares generó una señal falsa, que el programa tomó como señal de aterrizaje.El software, que se suponía que debía ignorar las respuestas del sensor hasta el momento en que se activó el algoritmo de detección de contacto con el suelo, se organizó incorrectamente y se almacenaron respuestas falsas en el sistema. Tan pronto como se activó el algoritmo para determinar el toque de la tierra a una altitud de 40 m, el programa emitió de inmediato una orden para apagar los motores de aterrizaje.A una altitud de 40 m, la velocidad de descenso del vehículo fue de aproximadamente 13 m / s (47 km / h), que, sin el empuje de los motores de freno, aumentó a 22 m / s (80 km / h) cerca de la superficie bajo la influencia de la gravedad de Marte, la velocidad estimada de disminución fue de 2,4 m / s (9 km / h). A tal velocidad de colisión con la superficie, el dispositivo no podría sobrevivir ".Si observa el algoritmo del programa, puede ver que una línea de restablecimiento del estado de la variable IndicatorState al FALSO inicial podría salvar el dispositivo, lo que costó a la NASA $ 328 millones.Diagrama de flujo de software Ariane 5
El 4 de junio de 1996, se realizó el primer lanzamiento del nuevo vehículo de lanzamiento Ariane 5 desarrollado por la Agencia Espacial Europea (ESA). El lanzamiento terminó en un fracaso: el cohete se estrelló en el 39º segundo del vuelo debido a un funcionamiento incorrecto del software a bordo.
El lanzamiento del primer Ariane 5Ariane 5 es el vehículo de lanzamiento europeo de la familia Ariane. Los lanzamientos se producen en el cosmódromo de Kourou en la Guayana Francesa. El desarrollo de Ariane 5 tomó 10 años, costó $ 7 mil millones y estaba destinado a reemplazar el vehículo de lanzamiento Ariane 4.Lanzado en 1996, un vehículo de lanzamiento con una masa de 720 toneladas lanzaría cuatro satélites con una masa de 1.2 toneladas cada uno. Rotando cada uno en su propia órbita, estos satélites forman un tetraedro, y trabajan en grupo, fue el proyecto del Clúster Europeo para estudiar el campo magnético de la Tierra (más tarde en 2000, dos nuevos satélites para el programa Cluster-II fueron puestos en órbita con éxito por dos vehículos de lanzamiento Soyuz) .El curso de los acontecimientos
Antes de describir el incidente, debe tenerse en cuenta que el diseño del sistema de navegación (Sistema de referencia inercial - SRI) para Ariane 5 es casi idéntico al diseño para Ariane 4, en particular con respecto al software.El momento de inicio se denota por H0. Las operaciones que precedieron al inicio ocurrieron en el modo normal hasta el momento H0 - 7 minutos, cuando se registró la violación del "criterio de visibilidad". Por lo tanto, el inicio se pospuso por una hora.A H0 = 12:33:59 UTC, se realizó un lanzamiento, que sucedió normalmente hasta el momento de H0 + 37 seg. En los siguientes segundos, se produjo una desviación brusca del cohete de un camino determinado, y luego se produjo una explosión.
Ariane 5 momento explosivo durante el primer lanzamientoEntonces: en este momento H0 + 39 seg. Después del lanzamiento, debido a la alta carga aerodinámica debido a que excedía el "ángulo de ataque" del valor crítico, los aceleradores de lanzamiento del cohete se separaron de su etapa principal, que sirvió de base para la inclusión del sistema de autoencendido del cohete.El cambio en el ángulo de ataque se produjo debido a la rotación anormal de las boquillas de los propulsores de combustible sólido, tal desviación de las boquillas de los aceleradores provocó un comando emitido por la computadora de a bordo basada en la información del sistema de navegación SRI 2. Parte de esta información en ese momento era incorrecta: lo que se interpretó como datos de vuelo fue en realidad de hecho, era la información de diagnóstico de la computadora incorporada del sistema SRI 2. La computadora incorporada SRI 2 transmitió datos incorrectos porque diagnosticó una situación anormal al "detectar" una excepción lanzada por uno de los módulos de software. Al mismo tiempo, la computadora de a bordo no pudo cambiar al sistema de respaldo SRI 1, ya que ya había dejado de funcionar durante el ciclo anterior (período de 72 ms). Por la misma razón que el SRI 2.La excepción "lanzada" por uno de los módulos de software SRI fue el resultado de convertir datos de un formato de punto flotante de 64 bits a un entero con signo de 16 bits, lo que condujo a un error de operando. Se produjo un error en un componente de software diseñado únicamente para realizar el "ajuste" de una plataforma inercial a bordo. Además, eso suena paradójico, pero este módulo de programa da resultados significativos solo hasta que el cohete se desprende de la plataforma de lanzamiento. Después de que despegó el cohete, este módulo no tiene efecto en el vuelo. Pero la función de ajuste, de acuerdo con los requisitos establecidos para ella, debe actuar durante otros 50 segundos. después del inicio del "modo de vuelo". Esta secuencia se basa en los requisitos para Ariane 4, pero no es necesaria para Ariane 5.El error "Error de operando" se produjo debido a una inclinación horizontal inesperadamente grande de BH (sesgo horizontal). El valor de BH resultó ser mucho más alto de lo esperado, porque la ruta de vuelo del Ariane 5 era significativamente diferente de la ruta de vuelo de Ariane 4. La acción final, que tuvo consecuencias fatales, fue el apagado de la computadora SPI incorporada; en consecuencia, todo el sistema de navegación dejó de funcionar. Era técnicamente imposible reanudar sus acciones. Toda esta cadena de eventos se reprodujo completamente mediante simulación por computadora. Los resultados de la simulación, así como los materiales de otros estudios y experimentos, permitieron a los expertos concluir que las causas y circunstancias del desastre se identificaron completamente.
Ariane 5 en la plataforma de lanzamiento antes de un lanzamiento exitoso, Guayana Francesa 2002.Puede encontrar varias opciones para eliminar el molesto error en el software Ariane 5 (estas opciones se reflejan en los resultados de la investigación), pero de una forma u otra, esta línea de código le costó al ESA $ 500 millones (El costo de un cohete con carga).También quiero señalar que en ninguna parte de los informes se hace hincapié en la impotencia del sistema de respaldo en Ariane 5 en este incidente, aunque en las conferencias del profesor. Hoffman este accidente se menciona solo en este contexto. Al tener dos sistemas duplicados idénticos SRI 1 y SRI 2, quizás podamos protegernos de problemas con el equipo físico en uno de los sistemas, pero cuando se trata de un error de software, dicha duplicación es simplemente inútil. Entonces Hoffman habla sobre el siguiente paso: duplicar el software, haciéndolo diferente (diferentes compañías, diferentes programadores). Parecería que con tal estructura, nos protegimos de los errores, pero tales medidas complican el sistema general y crean aún más lugares donde pueden ocurrir errores, y el tercer caso se da como ejemplo.Transbordador espacial
El 12 de abril de 1981, la nave espacial Columbia reutilizable bajo el programa del transbordador espacial realizó su primer vuelo de prueba desde el cosmódromo de Cabo Cañaveral.
Preparación para la misión STS-1: el primer vuelo del transbordador espacialEl curso de los acontecimientos
El 10 de abril de 1981, aproximadamente 20 minutos antes del lanzamiento programado, los astronautas y el personal del servicio de transporte intentaron lanzar un sistema de control de vuelo de respaldo, que duplicaba el sistema principal de cuatro computadoras, pero fallaron. El inicio se canceló 16 minutos antes del tiempo estimado y se pospuso por dos días.Cómo no recordar el notorio cómic Sucedió que el sistema de control de vuelo de respaldo BFS (Sistema de control de vuelo de respaldo) en la quinta computadora de a bordo no pudo sincronizarse con el sistema de control de vuelo primario PASS (Sistema de software de aviónica primario), que ya se estaba ejecutando en otras cuatro computadoras de a bordo. Hubo un error en el software: un error muy pequeño, casi increíble, muy sofisticado y muy antiguo al inicializar PASS.Para que el transbordador sea confiable, todo está duplicado en él: sensores, electrónica, sistema de control, computadoras, software, buses de datos, fuentes de alimentación. De hecho, para satisfacer el concepto de "falla - operacional, a prueba de fallas" "FO / FS" (Fail - Operational, Fail - Safe) muchos componentes se duplicaron 4 veces: ya sea literalmente (4 juegos de equipos) o de manera equivalente (circuitos alternos reemplazar uno o más de los cuatro bloques requeridos).El número cuatro fue elegido por una razón lógica e intuitiva: el principio FO / FS requiere que después de la primera falla, el equipo permanezca completamente operativo, y después de la segunda falla asegura un retorno seguro. El voto mínimo requiere tres votos, por lo que en la etapa inicial debe tener 4 votos para poder votar después de una negativa. El transbordador tenía 5 computadoras a bordo, cuatro de ellas tenían el mismo software y funcionaban en todas las etapas críticas del vuelo. Este enfoque es ideal en caso de problemas con las computadoras u otros equipos (según los cálculos, los errores en un sistema de tres computadoras causaron la pérdida del dispositivo en tres casos de un millón, y un sistema de cuatro computadoras redujo esta posibilidad a cuatro de cada mil millones), pero no funciona, dada la posibilidad de una críticaerror fatal en el software. Por lo tanto, la idea de software alternativo apareció en la quinta computadora, que realizaría la funcionalidad mínima de software en las primeras cuatro.El desarrollo de software para BFS incluyó las mismas especificaciones, el mismo lenguaje de programación, el mismo compilador y el mismo hardware donde se instaló este software. Pero fue desarrollado por una organización completamente diferente (Rockwell International para BFS e IBM, División de Sistemas Federales para PASS) e instalado en diferentes sistemas operativos. El sistema operativo para PASS era asíncrono y tenía una prioridad (por lo tanto, la tarea más importante siempre tiene control instantáneo sobre la computadora). BFS, por el contrario, se parece más a un sistema completamente sincronizado de "intervalos de tiempo", donde cada proceso tiene el tiempo asignado para completar su ciclo.Desafortunadamente, los sistemas síncronos y asíncronos están mal combinados. Para que BFS se sincronice con PASS, PASS debe ser sincrónico o emular esto para procesos sincronizados. El proceso de emulación se aseguró con una pérdida mínima en el desarrollo. Tan pronto como se encendió la primera computadora y se inició PASS, intentó sincronizar el comienzo de todos los procesos con los datos de telemetría de la nave. Esta sincronización se realizó leyendo el valor de tiempo de los datos de telemetría y calculando las fases de telemetría de acuerdo con el tiempo central.El viernes por la mañana, 10 de abril, quedó claro que algunos procesos en PASS no se están procesando en su fase: un ciclo antes que el resto de los procesos PASS y BFS. Suponiendo que recibió datos "contaminados", BFS, según se requirió, dejó completamente de "escuchar" la información de PASS y, por lo tanto, no pudo sincronizarse con PASS. Para BFS, los datos que ingresan al bucle solían ser solo una "interferencia" desequilibrada.Ya al comienzo de la tarde, después de reunir a todos los expertos, la NASA pudo aclarar la naturaleza del problema. El error en la fase podría corregirse con el antiguo método de abuelo: si algo no funciona, apáguelo y vuelva a encenderlo.
Pero este enfoque no funciona para una nave espacial totalmente cargada y lista para lanzar: las computadoras a bordo juegan un papel fundamental en el procesamiento de la información que viene "desde" y "hacia" el sistema de preparación del lanzamiento espacial.La información reunida por expertos y el hecho de que reiniciar las computadoras de a bordo el viernes por la noche solucionó el problema le dio a la gerencia de la NASA suficiente información para programar un lanzamiento el domingo por la mañana. Pero las verdaderas causas del error se revelaron el domingo por la noche, 8 horas después del lanzamiento.Las computadoras a bordo usan la cola del temporizador del sistema operativo como un reloj, el primer registro es la hora de inicio deseada del siguiente proceso, cuando se ejecutan cientos de procesos en cualquier segundo, el primer registro siempre muestra una hora actual bastante precisa (siempre a toda prisa, pero siempre lo suficientemente precisa). El tiempo resultante es siempre exactamente el mismo para todas las computadoras de respaldo a bordo. Cuando se inicia la primera computadora, no hay computación activa, este es el único momento en que la cola está vacía. Y como no hay otras computadoras que funcionen, se le permitió al primero usar su reloj para determinar la hora.Pero la línea no estaba vacía como estaba previsto. Dos años antes del lanzamiento, hubo un cambio en la rutina de inicialización del bus de datos, que se realizó antes de que se calculara la hora de inicio. Esta rutina insertó un valor de retraso en la cola del temporizador. Este cambio pasó desapercibido: al final, cómo se asocia la inicialización del bus con la determinación de las fases para la telemetría. Además, este retraso de tiempo fue lo suficientemente pequeño como para que la primera entrada en la cola esté cerca del presente. Pero un año después (un año antes del lanzamiento) se realizó otro cambio para corregir una posible sobrecarga del procesador, el tiempo de retraso aumentó ligeramente. Y esto fue suficiente para la probabilidad de 1/67 de que, cuando enciende la primera computadora a bordo, en sus cálculos de la hora de inicio,Usando un poco de tiempo de espera del temporizador de avance, podría obtener un resultado cuando la hora de inicio estaba en el pasado. Luego, el sistema operativo pospuso el inicio del proceso para un ciclo (como sucede con una alarma, cuando se establece en el "pasado", omite un ciclo de 12 horas para que pueda sonar en el "futuro"), lo que finalmente lleva al hecho de que casi todo los procesos se ejecutaron al final del ciclo.Las pruebas pudieron detectar este error, pero la probabilidad de un error apareció solo en las últimas etapas de la prueba, cuando se probó todo el sistema, pero incluso entonces, la mayoría de las pruebas no requirieron una inicialización desde cero. E incluso en las pruebas donde esto era necesario, se necesitaba un laboratorio con modelos bastante precisos de PASS, BFS y telemetría. E incluso si se cumplen todas las condiciones anteriores, cuando se produce un error, existía la tentación de reiniciar todo y ... nunca repetir el error, y nunca estar seguro de si esto era un problema en la configuración del laboratorio. Probablemente esto es exactamente lo que sucedió en uno de los laboratorios de la NASA unos 4 meses antes del vuelo.Y, sin embargo, el día en que se encendió la primera computadora a bordo, 30 horas antes del lanzamiento programado, el problema se hizo sentir.Toda la información sobre el error en el transbordador está tomada de un artículo de John Garman (jefe adjunto del departamento de software espacial de la NASA). En él, también escribe: “No se proporciona la confiabilidad ideal, porque los proyectos siempre tienen que negociar por tiempo y costo. Mantener sistemas de software en el lugar, acumular grandes cambios y adiciones en las etapas de desarrollo, y reconfigurar el software para que se ajuste a máquinas o misiones que nunca son completamente idénticas son los desafíos que enfrentamos hoy. Es fácil decir: "No rompas las reglas". Esto no es posible sin invertir la posición relativa del software en sistemas integrados, ¡y esto está mal! El software puede ser el "alma" de los sistemas más complejos, pero sigue siendo solo una parte del shell de soporte ... una parte muy flexible ".
El transbordador aterrizó en la superficie del lago Rogers seco.El costo de este error en el software es de $ 0 (por supuesto, los costos de transferir el lanzamiento probablemente fueron considerables, pero a la luz de los accidentes previos considerados, cuando la nave espacial se perdió por completo antes de completar su misión planificada, el costo de volver a entrenar el lanzamiento I descuidado, especialmente porque no pude encontrar datos adecuados).Pero me gustaría señalar que este error pospuso el tiempo de lanzamiento dos días: del 10 al 12 de abril y, en mi opinión, fue imposible elegir una fecha mejor para el primer lanzamiento del transbordador, porque el mismo día, exactamente hace 20 años Yuri Gagarin hizo su vuelo al espacio. ¿Cómo no recordar las palabras de una tortuga de que "la aleatoriedad no es accidental"? Source: https://habr.com/ru/post/es381073/
All Articles