Cómo NASA construyó la computadora tolerante a fallas de Artemis II

 (cacm.acm.org)
7 puntos por GN⁺ 19 일 전 | 1 comentarios | Compartir por WhatsApp
  • La computadora de vuelo de Orion, la nave tripulada lunar, tiene una arquitectura con mucha mayor resiliencia y capacidad de control automático que los sistemas de la era Apollo, y gestiona directamente todas las funciones críticas, como soporte vital, energía y comunicaciones
  • Para operar sin interrupciones incluso a 250 mil millas de distancia en órbita lunar, fue diseñada para resistir fallas de hardware y los efectos de la radiación mediante redundancia física y lógica, además de múltiples computadoras de vuelo
  • Cada Flight Control Module (FCM) está compuesto por un par de procesadores con verificación mutua; en total, 8 CPU ejecutan en paralelo, y una arquitectura fail-silent junto con un algoritmo de selección de salida basado en prioridades aísla los errores
  • El sistema mantiene una sincronización completa mediante Ethernet activado por tiempo y una arquitectura determinista, con red y memoria triplicadas que corrigen automáticamente incluso errores de un solo bit
  • Si todos los sistemas principales fallan, un Backup Flight Software basado en hardware y sistema operativo independientes toma el control; esta estructura es vista como un futuro modelo de resiliencia always-on para sistemas autónomos

Diseño de la computadora tolerante a fallas de Artemis II de NASA

  • La computadora de vuelo de Artemis II tiene una estructura con mucha mayor resiliencia y capacidad de control automático que la computadora de navegación de la era Apollo
    • La computadora de Apollo usaba un procesador de 1 MHz y cerca de 4 KB de memoria, y el control principal se apoyaba en interruptores manuales o relés
    • En la cápsula Orion de Artemis II, la computadora administra directamente todas las funciones críticas, como soporte vital, energía y comunicaciones
  • Como una falla de misión a 250 mil millas de distancia en órbita lunar sería irrecuperable, el sistema debe seguir funcionando sin interrupciones incluso frente a radiación espacial, bit flips y fallas de hardware
    • NASA preparó el sistema para fallas de hardware mediante cableado físicamente redundante, planos de red redundantes a nivel lógico y múltiples computadoras de vuelo

  • The Power of Eight

    • Orion adopta una arquitectura que va más allá de la redundancia triple (triple redundancy)
      • Cada una de las dos Vehicle Management Computer (VMC) incorpora dos Flight Control Module (FCM), para un total de 4 FCM
      • Cada FCM consiste en un par de procesadores con self-checking, por lo que un total de 8 CPU ejecutan en paralelo el software de vuelo
    • El sistema se basa en un diseño fail-silent: cuando una CPU presenta un error, no emite una salida incorrecta y pasa inmediatamente a estado silencioso
    • En lugar de votación por mayoría, usa un algoritmo de selección de fuente basado en prioridades para elegir la salida de un canal sano
    • NASA prevé errores transitorios durante el paso por los cinturones de radiación de Van Allen, y estima que la misión puede continuar con el último FCM incluso si pierde 3 FCM durante hasta 22 segundos
    • Un FCM en estado silencioso puede reiniciarse y volver a sincronizarse con los demás módulos para reincorporarse durante el vuelo

  • Mantener una operación determinista

    • Para mantener varias computadoras independientes en sincronización completa (lockstep), se aplica una arquitectura determinista (deterministic architecture)
    • Orion usa una red de Ethernet activado por tiempo (time-triggered Ethernet) para distribuir el tiempo en todo el sistema
      • El software de vuelo se ejecuta dentro de un major frame y un minor frame administrados por el planificador ARINC653
      • La partición temporal y espacial garantiza que las entradas y salidas queden perfectamente alineadas con la programación de la red
    • Cada FCM recibe las mismas entradas, ejecuta el mismo código y genera las mismas salidas
    • Cada segundo se mide el drift del reloj de los FCM y se recalibra según el tiempo de referencia de la red
    • Cualquier aplicación que no cumpla su deadline pasa automáticamente a estado silencioso y luego se resincroniza
    • El hardware usa memoria con redundancia modular triple (TMR) para corregir automáticamente errores de un solo bit, y la tarjeta de interfaz de red también compara rutas de tráfico duales para aplicar fail-silent cuando detecta errores
    • La red está triplicada en tres planos independientes, y todos los switches tienen funciones de self-checking

  • Sistema de respaldo final

    • NASA también se prepara para un common mode failure que pueda afectar simultáneamente a todos los canales principales
    • Para ello incorpora por separado un sistema Backup Flight Software (BFS)
      • El BFS está compuesto por hardware distinto, otro sistema operativo y software de vuelo simplificado desarrollado de forma independiente
      • Si el sistema principal falla, el BFS toma automáticamente el control y puede completar las fases dinámicas de la misión
      • Después, la tripulación puede intentar recuperar los FCM principales
    • La lógica fail-silent es esencial, pero para evitar que un error permanezca sin detectarse se requieren además watchdogs y monitoreo en múltiples capas
    • También fue diseñado para sobrevivir incluso a una pérdida total de energía (dead bus)
      • Cuando se restablece la energía, entra automáticamente en safe mode
      • Luego orienta los paneles solares hacia el Sol para recuperar energía y coloca la nave con la cola hacia el Sol para estabilización térmica
      • Después intenta restablecer la comunicación con la Tierra y, si hace falta, la tripulación puede ajustar manualmente el sistema de soporte vital

  • El futuro de la confiabilidad

    • El cambio de Apollo a Artemis implica un aumento drástico en la complejidad del software
      • En Apollo existían respaldos mecánicos, pero en Artemis el software se encarga de todo el control
    • NASA utiliza un flujo moderno de verificación que incluye simulación de entorno completo, pruebas de estrés Monte Carlo e inyección masiva de fallas (fault injection)
      • Con supercomputadoras simula toda la línea temporal del vuelo y verifica si el software puede recuperarse en modo fail-silent incluso ante fallas de hardware
    • La arquitectura de cero tolerancia de Orion es considerada un modelo de resiliencia always-on que también podría aplicarse en el futuro a vehículos autónomos y redes de control industrial

Lecturas relacionadas

1 comentarios

 
GN⁺ 19 일 전
Comentarios en Hacker News

  • Trabajé en VOS y rendimiento de bases de datos en Stratus desde 1989 hasta 1995
    Stratus era una empresa de sistemas tolerantes a fallos (fault-tolerant) basados en hardware, mientras que su competidor Tandem seguía un enfoque basado en software
    La arquitectura de Stratus era de tipo “pair and spare”, con todas las tarjetas duplicadas y comparando la salida de cada pin en cada tick
    Al pasar de Motorola 68K a Intel, el equipo de hardware tuvo serios problemas porque algunos pines no usados de ciertas instrucciones quedaban flotando

  • Me llamó la atención la frase de un investigador de CMU de que “Agile y DevOps debilitaron la disciplina arquitectónica”
    Da la impresión de que hoy hemos olvidado cómo construir sistemas deterministas
    La estricta programación de tramas de Time-triggered Ethernet se siente como un mundo completamente distinto al desarrollo de software actual

    • Todavía hay gente que trabaja con sistemas embebidos que necesitan garantías en tiempo real
      Algunas prácticas modernas de desarrollo, como pruebas unitarias y CI, también tienen un impacto positivo en estos entornos
    • En la era de Apollo, gracias al financiamiento de investigación centrado en defensa, la computación determinista basada en WCET (tiempo de ejecución en el peor caso) era lo dominante
      Ahora, con el cambio hacia un mercado más comercial, la inversión ha disminuido, pero todavía hay muchos algoritmos interesantes
      Vale la pena revisar trabajos de Frank Mueller o Johann Blieberger
    • Time-triggered Ethernet forma parte de los buses de datos para certificación aeronáutica, y INRIA y Airbus hicieron investigación relacionada
      En entornos con entradas y salidas limitadas, como una aeronave, el diseño determinista encaja perfectamente
      En la práctica, se parece más a un bus de hardware dedicado que a Ethernet
    • Escuché que la Tesla Cybertruck también usa este enfoque sobre Ethernet
    • Probablemente a lo que se refería era SpaceWire

  • Al ver el reto de ‘radiation hardening’ en Code Golf, me pregunté
    si este tipo de enfoque realmente tendría utilidad práctica
    En el mundo real sería difícil porque hay demasiados niveles de problemas entrelazados, pero aun así me parece una idea interesante

  • El diseño “fail-silent” explicado en el artículo me pareció interesante
    Pero me pregunto cómo detectarían el caso en que dos CPU hagan al mismo tiempo un cálculo incorrecto y además el resultado coincida

    • La probabilidad de que ocurra simultáneamente el mismo error de bit en dos CPU por radiación es extremadamente baja
    • Estas CPU funcionan en arquitectura lockstep, ejecutando las mismas operaciones al mismo tiempo y comparando resultados
      La probabilidad de que ambas produzcan el mismo error simultáneamente es mucho menor que el FIT de una sola CPU
    • La probabilidad de que dos CPU inviertan el mismo bit al mismo tiempo es probablemente menor que la de un impacto de asteroide
      Aun así, en el espacio aplica la ley de Murphy, así que no se puede asegurar nada
    • En realidad, incluso en una arquitectura de triple votación por mayoría aparece el mismo problema si dos CPU cometen el mismo error
    • Si los sistemas 1 y 2 fallan al mismo tiempo y los otros 6 están normales,
      un “25% de mayoría” podría terminar eligiendo el resultado incorrecto

  • Me gustaría conocer detalles concretos sobre la CPU, RAM, SO y lenguaje de este sistema
    También quisiera saber con qué frecuencia el FCM entró en estado “fail-silent”

    • NASA cFS está escrito en C y está publicado en GitHub
      Normalmente corre sobre FreeRTOS o RTEMS
      Personalmente, la estructura del proyecto me pareció demasiado compleja y difícil de manejar
    • BFS usa cFS, y también puede verse en este video de YouTube
      La mayor parte del código central de NASA no es público, pero cFS es un buen material para aprender diseño clásico de software de vuelo

  • El artículo omite detalles sobre el RTOS y la arquitectura reales
    El control principal de vuelo de Orion es una estructura cuádruple redundante basada en Green Hills INTEGRITY RTOS y procesadores BAE RAD750
    El BFS corre sobre hardware completamente distinto, LEON3 + VxWorks, y usa el framework cFS de NASA
    Esta es una arquitectura modular reutilizable que también se ha usado en el telescopio James Webb y en el Mars Rover
    Esta estructura no es simplemente “sistema principal + respaldo”, sino un concepto de redundancia disímil (dissimilar redundancy)
    Se puede ver más detalle en documento técnico de NASA 1, documento 2

    • Pero incluso si son equipos completamente distintos, pueden aparecer los mismos errores si usan el mismo material de estudio o la misma fuente de algoritmos

  • La fabricación real estuvo a cargo de Lockheed Martin y sus subcontratistas
    Que la prensa lo presente como si NASA lo hubiera construido directamente lleva a confusión

    • No creo que Lockheed hubiera creado por su cuenta un costoso sistema PowerPC con redundancia cuádruple sin que NASA lo pidiera
    • El BFS fue desarrollado principalmente dentro de NASA (según el testimonio de un amigo que participó directamente)
    • En la práctica, seguramente hubo una colaboración estrecha entre NASA y Lockheed
    • También salió el chiste de “piensa en una megacorporación”

  • Cuando trabajaba como desarrollador web hace 25 años, le pregunté a un amigo ex NASA “¿cómo manejaban los bugs?”
    y él se rió y respondió: “no había bugs”
    Los desarrolladores de hoy están acostumbrados a entornos donde, aunque algo falle, no hay vidas en juego

    • Cada industria tiene un estándar distinto de lo que significa “suficientemente bueno”
      En un servicio web puede significar pérdida de ingresos, pero en una nave espacial están en juego vidas humanas

  • Antes desarrollé una computadora resistente a la radiación,
    y además de la simple redundancia usamos técnicas no redundantes de detección de errores
    Me da pena no ver ese tipo de enfoque en este sistema

    • En la era del Shuttle, instalaban cinco computadoras en posiciones y orientaciones distintas
      y también aplicaban endurecimiento físico para dispersar la sección eficaz de colisión de la radiación

  • Aunque todas estas estructuras redundantes son excelentes, me pregunto si todavía es posible un control manual (Manual Override)
    Quisiera saber si aún se puede controlar directamente cuando hace falta, como en Apollo 11 y 13
    Como los astronautas siguen siendo pilotos de pruebas de formación, supongo que sí debe ser posible