¿Cuál fue la primera actualización de software "por aire" no planificada de una nave espacial?

Febrero a agosto, varias veces, 1969.

(TL;RD)

P:

¿Cuál fue la primera actualización de software "por aire" no planificada de una nave espacial?

A:

Las sondas Mariner 6 y 7 , lanzadas en 1969 para observar Marte, se diferenciaban de las sondas anteriores en que tenían nuevas computadoras que podían reprogramarse. Esto permitió, por primera vez, realizar cambios en las misiones que no estaban planificadas antes del lanzamiento.

• Por lo tanto, la reprogramación, ya sea planificada o no antes del lanzamiento, hubiera sido imposible antes de que las computadoras CCS se lanzaran en las sondas Mariner. Entonces, la fecha más temprana para una actualización de software OTA para cualquier nave espacial, en absoluto, serían estas dos sondas en 1969.

(Esto también condujo a que se usaran computadoras reprogramables y de respaldo en las misiones Viking, que a su vez usaron hardware idéntico en las misiones Voyager de 1977 con mejoras de software que permitieron controlar el motín de la Voyager 2).

Mariner 6 y Mariner 7 fueron naves espaciales idénticas lanzadas el 24 de febrero de 1969 y el 27 de marzo de 1969 respectivamente, y sus misiones se dedicaron por completo al estudio de sobrevuelo de Marte.

En tránsito a Marte, probablemente debido a una ruptura de la batería, el contacto se perdió temporalmente con Mariner 7 el 30 de julio. Después de un silencio de 7 horas, se restableció el contacto, pero pronto se hizo evidente que el instrumento responsable de informar la orientación de la televisión. las cámaras se habían dañado y ya no funcionaban. Sin esta información, las cámaras del Mariner 7 no podrían apuntar correctamente y, con el encuentro con Marte al alcance de la mano, se necesitaba una solución rápidamente.

El 1 de agosto, la calibración manual por parte de los equipos de tierra llevó a Marte a la vista de las cámaras del Mariner 7 y, el 2 de agosto, el Mariner 7 comenzó a transmitir imágenes de encuentros lejanos de Marte. La restauración del sistema de imágenes Mariner 7 fue un excelente ejemplo de la experiencia desarrollada por los operadores de la misión durante estas primeras misiones interplanetarias y el evento fue un testimonio de la importancia de tener una computadora reprogramable en la nave espacial .

https://nssdc.gsfc.nasa.gov/planetary/mars/mariner.html

El nuevo sistema Central Computer and Sequencer (CCS), utilizado por primera vez en esta misión, que permite una operación extremadamente flexible de la nave espacial utilizando la reprogramación en vuelo de la memoria de la computadora por comando de radio.

Las misiones anteriores empleaban un dispositivo de secuencia fija relativamente simple que tenía una serie de eventos preprogramados y cableados antes del lanzamiento. Los únicos eventos que se podían cambiar después del lanzamiento eran las duraciones de los giros, el incremento de la velocidad en la mitad de la ruta y el tiempo de la mitad de la ruta.

La diferencia con este nuevo sistema era que aunque este programa de vuelo se carga en su memoria de 128 palabras antes del lanzamiento, el CCS puede reprogramarse completamente en vuelo mediante un comando de radio.

Durante el vuelo de las naves espaciales Mariner VI y Mariner VII, el comando de tierra ha reprogramado el CCS muchas veces. Al 17 de junio de 1969 , el Mariner VI había recibido 575 comandos de radio y el Mariner VII había recibido 217.

La flexibilidad permitida por el CCS reprogramable permitió al equipo de operaciones llevar a cabo muchas secuencias que no habían sido planificadas previamente . También ha permitido enfoques alternativos cuando se han producido problemas en otros subsistemas de naves espaciales.

A modo de ejemplo, la calibración y las pruebas en el sistema de televisión de repuesto Mariner 1969 indicaron que el control de apertura automática se había colocado de una manera que podría causar un brillo excesivo en algunas de las primeras imágenes de televisión de encuentros cercanos. Esto fue el resultado de cambios bruscos de brillo detectados cuando el campo de visión de la televisión atravesó la línea que separaba la oscuridad del espacio y la parte brillante del planeta. El CCS fue reprogramado por comando desde tierra para provocar una secuencia automática que mantendría el control de apertura de la cámara en una posición de ganancia mínima durante varias imágenes, después de lo cual entraría en un modo de compensación automática.

Este es solo un ejemplo de muchos casos en los que el CCS se ha reprogramado para ajustarse a las variaciones de rendimiento, de modo que la nave espacial pueda llevar a cabo una misión nominal en caso de que ocurra una falla del sistema de comando en un momento posterior.

Discusión al final del artículo:

P. Usted menciona que la magnitud de la flexibilidad aumentó la eficiencia. ¿Qué quiere decir con eficiencia en este sentido? ¿Fue calculado o medido?

R. La mejora en la eficiencia de la misión Mariner 1969 es un ejemplo: durante el tiempo posterior al acercamiento máximo al planeta, se enviaron aproximadamente 300 comandos a la nave espacial para reprogramar la computadora digital a bordo, lo que permitió que la nave espacial realizara una serie de maniobras que cartografian completamente el cielo en el ultravioleta.

Esta fue una misión que no había sido diseñada en la nave espacial antes del lanzamiento , pero fue posible gracias a que pudimos reprogramar el sistema de control desde tierra. Las mejoras de la misión se realizaron mediante la reprogramación de la computadora digital.

https://www.sciencedirect.com/science/article/pii/S1474667017687755

La reprogramación en vuelo, que comenzó cuando los secuenciadores programables volaron en los Mariner y se llevaron a un estado de alta calidad en el Mariner X, era una tarea casi rutinaria en el momento del lanzamiento de la Voyager en 1977. Tanto el CCS como la computadora del sistema de datos de vuelo tienen ha sido reprogramado extensamente.

https://history.nasa.gov/computers/Ch6-2.html

En una nota final, no la primera, pero ciertamente una que me vino a la mente de inmediato, además de Viking y Voyager (al mirar a Viking noté a Mariner ...), para la reprogramación fue el International Sun-Earth Explorer-3 (ISEE-3 ) satélite - reprogramado para convertirse en ICE.

https://en.wikipedia.org/wiki/International_Cometary_Explorer

y por ultimo un video:

Programas Mariner 6 y 7 Misiones a Marte, 1969 Película HACL 00033

A las 8:58 menciona los comandos enviados a Mariner.

y por último, esto me recuerda a Voyager, pero al revés:

https://meh.com/forum/topics/construyendo-el-avion-en-el-camino-arriba

Cuando se lanzaron las sondas Voyager con codificadores Reed-Solomon a bordo, no existían decodificadores Reed-Solomon en la Tierra.

También, como un aparte:

El software de análisis y control original de Voyagers se escribió en Fortran 5.

Estudio de la NASA sobre la complejidad del software de vuelo

Growth in Code Size:

1969 Mariner-6 (30)
1975 Viking (5K)
1977 Voyager (3K)
1989 Galileo (8K)
1990 Cassini (120K)
1997 Pathfinder (175K)
1999 DS1 (349K)
2003 SIRTF/Spitzer (554K)
2004 MER (555K)
2005 MRO (545K)
1968 Apollo (8.5K)
1980 Shuttle(470K)
1989 ISS (1.5M)

https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf

Casi pérdida de SOHO
Hay tres "primicias" que creo que son relevantes para esta pregunta. El primero es la casi pérdida de SOHO el 24 de junio de 1998. Puede leer los detalles en la página de Wikipedia, pero el resumen es que el equipo de operaciones de vuelo estaba realizando algunas pruebas normales de control de actitud cuando los sensores de la nave espacial perdieron de vista el Sol, lo que provocó que la nave espacial entrar en pánico Todo el esfuerzo terminó después de casi un año y el equipo de operaciones de vuelo tuvo que diseñar, escribir e implementar un nuevo sistema de control de actitud que no dependiera de los giroscopios que ahora no funcionan. Creo que esta última parte satisface su aspecto "no planificado" de una actualización de software, ya que no puedo prever que piensen en cómo controlar la nave espacial sin los giroscopios durante la fase inicial de diseño de la misión.

Pérdida de STEREO-B
El segundo problema no planificado ocurrió durante la pérdida de STEREO -B. Si bien la página de Wikipedia no detalla exactamente lo que sucedió, el problema real fue que APL estaba realizando algunas maniobras de actitud (el 1 de octubre de 2014) en previsión de que la nave espacial se colocara detrás del Sol (en relación con la Tierra). Vea que la nave espacial tuvo que "dar la vuelta" antes de pasar detrás del Sol para que, al salir del limbo solar, la antena de alta ganancia apuntara hacia la Tierra. El equipo comenzó a realizar maniobras (tenga en cuenta que la nave espacial estaba sobre una unidad astronómicade distancia, es decir, a más de 8 minutos luz) y de repente se dio cuenta de que algo andaba mal. Rápidamente determinaron que la nave espacial había entrado en un giro descontrolado, pero no elevaron el problema a una emergencia (es decir, esto les habría permitido usar la Red de espacio profundo (DSN)inmediatamente y probablemente habría recuperado la nave espacial). La nave espacial no pudo reorientarse por sí sola porque giraba demasiado rápido, por lo que entró en modo seguro esperando ayuda. Su eje de giro permanecería más o menos fijo en relación con su línea inicial entre la nave espacial y el Sol, por lo que con el tiempo los paneles solares ya no estarían iluminados y moriría. Después de cuatro años, la NASA finalmente dejó de intentar recuperar la nave espacial. En este caso, la parte "no planificada" fueron todos los esfuerzos para intentar desviar una nave espacial cuando la comunicación es intermitente y luego tratar de recuperar la nave espacial después de que salió por detrás del Sol.

Nota al margen interesante: la gente de operaciones de vuelo inicialmente no se dio cuenta de que tendrían que voltear la nave espacial después de que pasara detrás del Sol, ya que eso estaba mucho más allá de la vida útil planificada de la misión, entre otras cosas.

Doble SEU en Wind
El tercer problema no planificado ocurrió a fines de octubre de 2014 cuando la nave espacial Wind tuvo dos perturbaciones simultáneas de un solo evento (SEU)en su hardware de comando y manejo de datos (C&DH). El equipo de operaciones de vuelo, junto con DSN, tuvo que adquirir manualmente la nave espacial (que todavía me parece increíble) ajustando manualmente la orientación de uno de los platos de 34 metros en DSN. Una vez hecho esto, tenían que diagnosticar y corregir el problema utilizando únicamente el flujo de telemetría en tiempo real. Esto dio como resultado que al menos dos de los ingenieros de operaciones de vuelo tuvieran que desenterrar las viejas carpetas de tres anillos del código de comando de la nave espacial y luego traducirlo en tiempo real (es decir, miraron las carpetas de tres anillos mientras escribían) al actual software utilizado por DSN. Luego tuvieron que reconstruir y reescribir completamente las tablas de comando de la nave espacial (SCT) desde cero (algunas se actualizan y cambian cada pocos días durante los intervalos habituales de enlace descendente, pero no todas). Esto se elevó a una emergencia de inmediato y la nave espacial se recuperó a un estado operativo dentro de ~ 11 días (las naves espaciales antiguas tardan mucho tiempo en volver a cargar SCT completos y solo nos dieron ~ 3-4 horas por día después de que se estableció podríamos contactar con la nave espacial a voluntad). La nave espacial volvió a las operaciones científicas completas después de otros ~ 20 días más o menos. En este caso, la parte "no planificada" fue la recreación de los SCT, el diagnóstico de una nave espacial que aparentemente no responde usando solo telemetría en tiempo real en un modo de baliza, y usando el segundo procesador C&DH hasta que el primero pudiera restablecerse y reprogramarse correctamente.

Nota al margen interesante: el segundo procesador de comando y actitud (CAP2) no se había utilizado hasta que ocurrió esta anomalía. Los CAP contienen el codificador de error que asegura que los bits recibidos en la Tierra sean los correctos (p. ej., codificador Reed-Solomon). El codificador Reed-Solomon en CAP1 falló en 1997, pero todavía tenía un codificador de convolución, por lo que seguía funcionando bien. No se sabía antes de esto, pero al usar CAP2, la gente de operaciones de vuelo descubrió que el codificador de convolución había fallado. El diseño de los codificadores permitió omitir electrónicamente el codificador Reed-Solomon pero no el codificador de convolución, por lo que nos dimos cuenta de que no podíamos confiar en CAP2 para las operaciones y teníamos que recuperar CAP1 por completo. Se encontró que la tasa de error sin un codificador es solo de 1 en 10,000 bits (o 1 bit en cada ~ 1250 bytes), pero eso sigue siendo problemático si es un bit que informa al código dónde apuntar en un archivo binario cuando busca datos. Entonces, la recuperación de CAP1 comenzó aproximadamente un mes después de que las operaciones se restauraron por completo utilizando CAP2 y CAP1 se restableció como principal aproximadamente un mes después de eso (es decir, aproximadamente el 30 de enero de

Estoy seguro de que hay otros ejemplos más interesantes, pero estos fueron los primeros que se me ocurrieron.