¿Cómo arregló la NASA de forma remota el código en el Mars Pathfinder?

Específicamente, para el problema de inversión de prioridad de Mars Pathfinder, esto se explica en detalle en Mars Pathfinder: Priority Inversion Problem , Report for the Seminar Series on Software Failures, Risat Mahmud Pathan, Chalmers University of Technology (PDF). Estoy reproduciendo aquí un extracto que es más relevante para su pregunta, y recomendaría leer el resto de la fuente:

2.2 ¿Cómo se depuró?

El software de Mars Pathfinder tenía varias funciones de depuración. Una de estas herramientas es una función de seguimiento/registro. La característica permaneció en el software en la versión final del diseño porque los ingenieros de JPL tienen la filosofía de que "prueba lo que vuelas y vuelas lo que pruebas" . Por lo tanto, no eliminaron la función de depuración; fue allí en Marte. Después de que ocurriera el problema en Marte, ejecutaron el mismo conjunto de actividades registradas (enviadas por Pathfinder antes de reiniciar) una y otra vez en el laboratorio y en tres semanas pudieron reproducir el error en la réplica en JPL. El problema de inversión de prioridad era obvio. La solución es habilitar la herencia de prioridad configurando el indicador mutex para las llamadas select() de ASI/MET en "on". Sin embargo, la solución no es tan obvia por varias razones:

Preocupación 1 : establecer el indicador de exclusión mutua es una opción global y, por lo tanto, aplicable a todas las exclusiones mutuas. Habilitarlo para ASI/MET lo habilitaría para otras tareas. ¿Cómo cambiaría esto el comportamiento del resto del sistema?

Preocupación 2: Wind River ¹ "desactivó" deliberadamente la opción de herencia prioritaria para un rendimiento óptimo. ¿Cómo se degradará el rendimiento si activamos la herencia de prioridad?

Preocupación 3 : ¿Se volvería incorrecto el mecanismo select() si la herencia de prioridad estuviera habilitada?

Wind River concluyó que el impacto en el rendimiento sería mínimo y que el comportamiento de select() no cambiaría. Los ingenieros de JPL probaron, analizaron y concluyeron que cambiar la bandera a nivel mundial no tuvo un impacto adverso. Entonces, decidieron parchear el software en Mars habilitando la opción de herencia de prioridad.

2.3 ¿Cómo se subió el parche?

VxWorks contenía un intérprete de lenguaje C para ejecutar declaraciones sobre la marcha durante la depuración. Los ingenieros del JPL decidieron lanzar la nave espacial con esta característica aún habilitada. Se cargó un breve programa C en la nave espacial, que cuando se interpretó, cambió los valores de la bandera de exclusión mutua para la herencia de prioridad de falso a verdadero. ¡No se produjo más reinicio del sistema!

La fuente citada también enumera varias referencias que vale la pena leer, pero para obtener una descripción general del problema y su solución, recomendaría a Tom Durkin, What the Media Couldn't Tell You About Mars Pathfinder , Robot Science and Technology Magazine, Número 1, 1998 ( PDF) que incluye explicaciones de Glenn E. Reeves (JPL).

En la primera revisión de mi respuesta , respondí por mi error con el problema FLASH del rover Spirit (Mars Exploration Rover, o MER-A), por lo que si está interesado en cómo se solucionan esos problemas en un sentido más general, entonces esa sub-respuesta (¿es esa la palabra?) debería darle una pista de que realmente depende de cada hardware específico y la naturaleza del problema. Pathfinder usó hardware COTS (comercial, listo para usar) con el procesador RAD6000 reforzado con radiación de IBMy Wind River vxWorks RTOS. Otros módulos de aterrizaje y rovers de Marte, a menos que sean de la misma serie como Spirit MER-A y Opportunity MER-B, pueden usar una combinación diferente de hardware y sistema operativo. Y aunque RAD6000 (Pathfinder, Mars Polar Lander, MER-A y MER-B, Phoenix Polar Lander) y vxWorks RTOS (Pathfinder, Spirit, Opportunity, Curiosity) parecen ser una combinación de procesador y sistema operativo bastante popular en Marte, son tampoco los únicos (Sojourner rover que Pathfinder implementó usaba un sistema operativo ejecutivo cíclico personalizado no muy diferente a la plataforma Arduino actual, Curiosity usa RAD750 PowerPC,...).

El canal de comunicaciones para enviar estas actualizaciones al hardware en Marte es la Red de Espacio Profundo (DSN) de la NASA que utiliza orbitadores de Marte para transmitir comunicaciones hacia y desde rovers, módulos de aterrizaje y otros. en el suelo del planeta rojo (puedes observar su estado en DSN Now ). Para el hardware distante donde el retraso de las comunicaciones podría ser de decenas de minutos, los comandos generalmente se transmiten en sesiones durante un día marciano completo (sol) o más por adelantado y, cuando es necesario (como con los cambios en el FSW - software de vuelo ), primero se cargan y probado en réplica que se queda en casa. Los protocolos de red exactos pueden ser diferentes, desde la frecuencia de radio hasta el tamaño y la estructura del paquete (hoy en día, se encuentra principalmente en DTN de banda X: redes tolerantes a demoras ).), pero todos estarían programados para escuchar con su subsistema de comunicación en frecuencias específicas para los comandos recién emitidos y programarlos de acuerdo con los indicadores de prioridad dentro de los datos recibidos. Algún hardware en Marte (como Mars Science Laboratory, mejor conocido como Curiosity) usa una plataforma de bus dual para redundancia y tolerancia a fallas, pero dado que eso aumenta el tamaño, la masa, el consumo de energía, etc., los más pequeños no lo hacen.

¹ Wind River Systems suministró los sistemas operativos en tiempo real VxWorks para la misión Mars Pathfinder.

Generalmente, las sondas espaciales tienen varias copias del sistema operativo. El que se está ejecutando, y uno que también puede intercambiar, y a menudo un tercero que es un modo seguro/alternativo que es más simple y permite reinicios remotos.

Cargarían el nuevo código en una de las ubicaciones de la memoria de respaldo, luego cambiarían para ejecutarlo una vez que estuviera completo.