¿Has lidiado con el endurecimiento del espacio?

Estoy muy ansioso por estudiar las mejores prácticas cuando se trata de endurecer el espacio. Por ejemplo, he leído (aunque ya no puedo encontrar el artículo) que algunas partes centrales de los rovers de Marte no usaban asignación de memoria dinámica, de hecho, estaba prohibido. También he leído que la memoria central antigua puede ser preferible en el espacio.

Estaba mirando algunos de los proyectos asociados con el Desafío Lunar de Google y me preguntaba cómo sería obtener un código en la luna, o incluso solo en el espacio. Sé que las placas endurecidas en el espacio ofrecen cierta cordura en un entorno tan hostil, sin embargo, me pregunto (como programador en C) ¿cómo necesitaría ajustar mi pensamiento y mi código si escribiera algo que se ejecute en el espacio?

Creo que los próximos años podrían mostrar un mayor crecimiento en las empresas espaciales privadas, realmente me gustaría al menos tener un poco de conocimiento sobre las mejores prácticas.

¿Qué le sucede a un programa si la radiación, el frío o el calor bombardean una placa que sufrió daños en su aislamiento? Creo que el objetivo es mantener a los humanos dentro de una nave espacial (en cuanto a arreglar o intercambiar cosas) y evitar misiones para arreglar cosas.

Además, si la junta mantiene algún sistema crítico, las advertencias tempranas parecen primordiales.

¿Cómo se gana experiencia en esto a través de pruebas y prueba y error (salvo el lanzamiento de su propio satélite personal)?

El software espacial no es magia arcana. Todavía estás usando 0's y 1's, no 1's y 3's. Por lo tanto, probablemente no haya un factor sorpresa involucrado en la descripción de lo que implica el desarrollo de software.

Algunas pequeñas diferencias que vienen a la mente en este momento son:

• Extremadamente orientado al proceso.
• El software espacial siempre tendrá temporizadores de vigilancia de software y hardware.
• Cada sistema espacial en el que he trabajado era un sistema duro en tiempo real.
• Simula (con gran precisión) todos los actores externos del sistema. Esto generalmente implica la construcción de hardware personalizado (a veces realmente costoso) que se usa únicamente para pruebas.
• Usted gasta un enorme esfuerzo y gasto haciendo pruebas formales.
• El cliente (generalmente JPL) está extremadamente involucrado en el proceso de prueba.
• Generalmente está utilizando compiladores y entornos de desarrollo antiguos y conocidos, en lugar de los nuevos.
• Revisiones de código, revisiones de código y revisiones de código.
• Será mejor que te sientas muy cómodo cambiando entre los mundos de hardware y software. No tiene que saber cómo diseñar el hardware, pero debe saber cómo funciona.
• Uso extenso de equipos de prueba, como osciloscopios, analizadores lógicos, sintetizadores y analizadores de espectro.
• Al menos 3 ubicaciones para almacenar el programa de aplicación. El valor predeterminado se graba en ROM. Esto nunca cambiará. Los otros 2 son para la versión actual y la próxima / última versión.
• El análisis de fallas (MTBF) es realmente importante.
• Sistemas redundantes y planes de conmutación por error para los componentes críticos.

Me topé con tu interesante pregunta.

Estuve en el Laboratorio de Instrumentación durante Apollo, y nuevamente cuando se llamó Draper Lab durante la "guerra fría".

Para la computadora de guía Apollo, el núcleo se usó para RAM y un núcleo trenzado especial para ROM. La máquina en sí estaba hecha completamente de puertas NOR y tenía una velocidad de reloj bastante lenta, para mayor confiabilidad.

No trabajé directamente en misiles Minuteman, pero estaba al tanto de algunos de los problemas. Si una cabeza nuclear se dispara cerca de algunos dispositivos electrónicos, básicamente se acorta. La computadora de guía tenía un sensor de radiación que apagaba instantáneamente Vc para que nada se quemara. Luego, la computadora se reiniciaría, habiendo borrado sus registros.

Para manejar esto, la computadora periódicamente toma instantáneas de sus registros en el núcleo, y cuando se reinicia, se iniciará desde ese punto de control. Para que esto funcione, el software (todo en ASM) tuvo que ser analizado para ver que podía recibir cualquier cantidad de esos golpes, en cualquier frecuencia, sin obtener respuestas incorrectas. Eso se llamaba "reiniciar protegido". Problema muy interesante, dado que (gracias a Dios) nunca tuvo que usarse.

Para obtener una confiabilidad de entorno difícil específicamente en C, aquí hay algunas cosas realmente concretas que he visto hacer.

MISRA-C: El subconjunto automotriz C. Un poco como Ravenscar ADA / Java.

perros guardianes: asegúrese de que el programa no se bloquee

memoria ecc (a veces)

sumas de comprobación: en busca de bits de volteo. He visto los tres en un solo sistema:

1) comprueba el programa de forma continua (estaba en EPROM pero todavía tenía bits invertidos).

2) suma de verificación de ciertas estructuras de datos periódicamente.

3) Verificaciones de la cordura de la CPU periódicamente.

4) compruebe que los registros IO tienen lo que se supone que deben tener en ellos.

4b) vuelva a leer las salidas en entradas independientes y verifique.

Mucho más importantes que el lenguaje de programación son los requisitos del sistema subyacente (SO y hardware). Básicamente, debe garantizar (y demostrar) un comportamiento determinista y predecible del sistema general. Se ha realizado mucha investigación relacionada en la comunidad en tiempo real. Recomiendo leer dos libros si realmente desea estudiar este tema: Real-Time Systems de Jane Liu y un libro con el mismo nombre de Hermann Kopetz . El primero cubre la programación de una manera muy teórica, mientras que el segundo pone los pies en el suelo y cubre casi todos los aspectos relacionados del diseño del sistema (en tiempo real), por ejemplo, tolerancia a fallas.

Además, los siguientes dos incidentes ilustran muy bien la calidad de los problemas que los ingenieros de software deben enfrentar al enviar algo al espacio:

• Ariane 5 (Reutilización de software probado bajo diferentes restricciones)
• Reinicio de Mars Rover Pathfinder (inversión de prioridad)

Encontré este documento (circa 2009) para el Estándar de codificación institucional JPL para el lenguaje de programación C en el Laboratorio de software confiable (LaRS) en el sitio del Laboratorio de propulsión a chorro .

Aquí hay un resumen de las reglas documentadas:

1. Cumplimiento de idioma

   • No te desvíes de la definición del idioma.
   • Compilar con todas las advertencias habilitadas; use analizadores de código fuente estático.

2. Ejecución predecible

   • Utilice límites de bucle verificables para todos los bucles destinados a terminar.
   • No use recursividad directa o indirecta.
   • No utilice la asignación de memoria dinámica después de la inicialización de la tarea.
   • * Use mensajes IPC para la comunicación de tareas.
   • No use retrasos de tareas para la sincronización de tareas.
   • * Transferencia explícita de permiso de escritura (propiedad) para objetos de datos compartidos.
   • Coloque restricciones sobre el uso de semáforos y cerraduras.
   • Use protección de memoria, márgenes de seguridad, patrones de barrera.
   • No use goto, setjmp o longjmp.
   • No utilice asignaciones de valores selectivos a elementos de una lista de enumeraciones.

3. Codificación defensiva

   • Declarar objetos de datos en el nivel de alcance más pequeño posible.
   • Verifique el valor de retorno de las funciones no anuladas, o expórtese explícitamente a (void)
   • Verifique la validez de los valores pasados ​​a las funciones.
   • Use aserciones estáticas y dinámicas como controles de cordura.
   • * Utilice U32, I16, etc. en lugar de tipos de datos C predefinidos, como int, short, etc.
   • Explique explícitamente el orden de evaluación en expresiones compuestas.
   • No use expresiones con efectos secundarios.

4. Claridad de código

   • Haga un uso muy limitado del preprocesador C.
   • No defina macros dentro de una función o un bloque.
   • No defina ni redefina las macros.
   • Coloque #else, #elif y #endif en el mismo archivo que #if o #ifdef coincidentes.
   • * No coloque más de una declaración o declaración por línea de texto.
   • * Use funciones cortas con un número limitado de parámetros.
   • * No use más de dos niveles de indirección por declaración.
   • * No use más de dos niveles de desreferenciación por referencia de objeto.
   • * No oculte las operaciones de desreferencia dentro de macros o typedefs.
   • * No utilice punteros de función no constantes.
   • No convierta punteros de función en otros tipos.
   • No coloque código o declaraciones antes de una directiva #include.

*) Todas las reglas se deberá reglas, excepto los marcados con un asterisco.

Los sistemas informáticos a prueba de espacio tienen que ver con la fiabilidad. Algirdas Avižienis, Jean-Claude Laprie y Brian Randell pueden encontrar una introducción profunda al campo en Conceptos fundamentales de confiabilidad .

El tiempo real también es un concepto clave para la informática espacial. Como Pankrat, recomendaría Sistemas en tiempo real de Hermann Kopetz.

Para dar una idea pragmática de los desafíos de la informática espacial, piense en:

• condiciones extremas en el espacio: mucho calor cuando se orienta al sol, mucho frío al otro lado, muchos rayos cósmicos que pueden invertir bits en la memoria, enormes aceleraciones y vibraciones cuando se lanzan, ... El hardware para el espacio debe ser mucho más robusto que el hardware para militares

• Cuando ocurre una falla, excepto en la Estación Espacial Internacional o para el telescopio espacial Hubble, nadie viene y reemplaza el sistema fallido. Todo debe arreglarse desde el suelo a través de la máxima observabilidad y comandabilidad y a través de sistemas de repuesto para cambiar. Esto es fácil para los satélites de la Tierra. Esto es más difícil con sondas espaciales para las cuales los retrasos en la comunicación pueden durar una hora. De hecho, todo debe ser lo más confiable posible en primer lugar.

Lo que aprendí del único proyecto en el que participé como pasante:

¡Sus especificaciones de hardware cambiarán, generalmente para peor!

Por ejemplo, se prometió, se le prometió , que la CPU reforzada con el espacio que se estaba utilizando en el diseño funcionaría a 20 MHz.

El resultado final corrió a 12 MHz. El programador senior del proyecto pasó mucho tiempo rediseñando algoritmos para cumplir con los requisitos en tiempo real de los sistemas de control y gran parte del software de telemetría terminó descargado en un segundo sistema en lugar de ejecutarse en la CPU principal.

Por lo tanto, intente dejar algunos recursos adicionales disponibles en el diseño original e intente no usar toda la CPU y memoria disponibles.

Para una perspectiva de software, escriba una tarea privilegiada que ocasionalmente, al azar, voltee bits en su código, y vea cómo se ocupa de eso. Ese es tu simulador.

En cuanto al hardware, las piezas serán viejas, porque lleva mucho tiempo conseguir que algo tenga una clasificación espacial. Además, las piezas nuevas se reducen continuamente en tamaño, y cuanto más pequeña es una característica (piense en la celda de memoria en un IC), más susceptible es a la corrupción por un evento de radiación.

Trabajé en un dispositivo crítico de seguridad y tuvimos que pasar por algunos aros similares.

Teníamos variables críticas de seguridad. Había una copia del inverso de la variable. Después de cada ciclo, la variable se verificó contra su inversa.

Tuvimos una prueba de caminar y ceros de TODOS los registros. ¡Eso incluyó el contador del programa!

Tuvimos una prueba de todos los códigos de operación del conjunto de micro instrucciones. Teníamos que asegurarnos de que si agregabas 2 registros, se agregaban los registros.

Algo de esto probablemente no esté relacionado con programas en el espacio, pero le da una idea de la magnitud de la verificación que es posible.

Creo que cuanto peor es un entorno, más códigos de corrección de errores se usan, y hay memorias ECC que se pueden usar hasta cierto punto.

Si se puede estimar el nivel de errores, se puede construir un código de corrección de errores que pueda manejar los errores introducidos.

• Sí, la memoria central está en los tableros de investigación.
• La memoria dinámica no es buena para los sistemas integrados. Problemas de fiabilidad.

Supongo que el software ECC de datos y el uso de la teoría de la información y un cargador personalizado para difundir los datos en todo el sistema para gestionar las fallas de memoria sería un comienzo. Pero, no estudio el software rad-hard, así que no estoy familiarizado con eso, eso es solo una suposición.