¿Ha lidiado con el endurecimiento del espacio?

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

Algunas diferencias leves que vienen a la mente en este momento son:

• Extremadamente orientado al proceso.
• El software espacial siempre tendrá temporizadores de vigilancia de hardware y software.
• Todos los sistemas espaciales en los que he trabajado eran difíciles en tiempo real.
• Simulas (con gran precisión) a todos los actores externos del sistema. Por lo general, esto implica la creación de hardware personalizado (a veces realmente costoso) que se usa únicamente para las pruebas.
• Usted gasta un enorme esfuerzo y gasto haciendo pruebas formales.
• El cliente (generalmente JPL) está extremadamente involucrado en el proceso de prueba.
• Por lo general, está utilizando compiladores y entornos de desarrollo antiguos y conocidos, en lugar de los nuevos.
• Revisiones de códigos, revisiones de códigos y revisiones de códigos.
• Será mejor que te sientas cómodo cambiando entre el mundo del hardware y el del software. No tiene que saber cómo diseñar el hardware, pero debe saber cómo funciona.
• Uso extensivo 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 la ROM. Esto nunca cambiará. Los otros 2 son para la versión actual y la siguiente / ú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 más tarde, cuando se llamó Draper Lab durante la "guerra fría".

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

No trabajé directamente en misiles Minuteman, pero estaba al tanto de algunos de los problemas. Si una ojiva nuclear se dispara en las proximidades de algunos componentes electrónicos, básicamente la corta. La computadora de guía tenía un sensor de radiación que se apagaría instantáneamente Vc para que nada se quemara. Luego, la computadora se reiniciará y se borrarán sus registros.

Para manejar esto, la computadora periódicamente colocará instantáneas de sus registros en el núcleo, y cuando se reinicie se iniciará desde ese punto de control. Para hacer que esto funcionara, el software (todo en ASM) tenía que ser analizado para ver que podía recibir cualquier número de tales hits, en cualquier frecuencia, sin obtener respuestas incorrectas. Eso fue llamado ser "reinicio 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 de C automotriz. Un poco como Ravenscar ADA / Java.

watchdogs: asegúrese de que el programa no se bloquee

memoria ecc (a veces)

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

1) verifica el programa continuamente (estaba en EPROM pero aún así se le dio la vuelta).

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

3) La salud mental de la CPU comprueba periódicamente.

4) los registros de IO check tienen lo que se supone que tienen en ellos.

4b) lee las salidas en entradas independientes y verifica.

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

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

• Ariane 5 (Reutilización de software probado bajo diferentes restricciones)
• Reinicio del explorador de Mars Rover (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 para Software Confiable (LaRS) en el Laboratorio de Propulsión a Chorro .

Aquí hay un resumen de las reglas documentadas:

1. Cumplimiento de idiomas

   • No se desvíe de la definición de idioma.
   • Compilar con todas las advertencias habilitadas; Utilice analizadores de código fuente estático.

2. Ejecución predecible

   • Utilice límites de bucle comprobables para todos los bucles que se pretende que terminen.
   • No utilice recursión directa o indirecta.
   • No utilice la asignación de memoria dinámica después de la inicialización de la tarea.
   • * Usa mensajes IPC para la comunicación de tareas.
   • No utilice retrasos de tareas para la sincronización de tareas.
   • * Transferir explícitamente el permiso de escritura (propiedad) para objetos de datos compartidos.
   • Coloque restricciones en el uso de semáforos y bloqueos.
   • Utilice protección de memoria, márgenes de seguridad, patrones de barrera.
   • No utilice goto, setjmp o longjmp.
   • No use asignaciones de valores selectivos a elementos de una lista de enumeración.

3. Codificación defensiva

   • Declare los objetos de datos en el nivel de alcance más pequeño posible.
   • Verifique el valor de retorno de las funciones no nulas, o realice una conversión explícita a (nula).
   • Compruebe la validez de los valores pasados a las funciones.
   • Utilice aserciones estáticas y dinámicas como controles de validez.
   • * Use U32, I16, etc. en lugar de tipos de datos C predefinidos como int, short, etc.
   • Haga explícito el orden de evaluación en expresiones compuestas.
   • No utilice expresiones con efectos secundarios.

4. Claridad del 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 macros.
   • Coloque #else, #elif, y #endif en el mismo archivo que el #if o #ifdef correspondiente.
   • * No coloque más de una declaración o declaración por línea de texto.
   • * Usa funciones cortas con un número limitado de parámetros.
   • * No utilice más de dos niveles de indirección por declaración.
   • * No utilice 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 constante.
   • No convierta punteros de función en otros tipos.
   • No coloque el código o las declaraciones antes de una directiva #include.

*) Todas las reglas son deberán reglas, excepto aquellas marcadas con un asterisco.

Los sistemas informáticos a prueba de espacio se basan en la fiabilidad. Una introducción profunda al campo se puede encontrar en Conceptos fundamentales de confiabilidad por Algirdas Avižienis, Jean-Claude Laprie & Brian Randell.

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

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

• condiciones extremas en el espacio: muy calientes cuando están orientadas al sol, muy frías al otro lado, muchos rayos cósmicos que pueden invertir bits en la memoria, grandes 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 fallado. Todo debe ser arreglado desde el suelo a través de la máxima observabilidad y ordenabilidad 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 las sondas espaciales para las cuales los retrasos de comunicación pueden durar una hora. De hecho, todo debe ser lo más confiable posible en primer lugar.

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

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

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

El resultado final se ejecutó a 12 MHz. El programador senior del proyecto dedicó mucho tiempo a rediseñar algoritmos para cumplir con los requisitos de 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 utilizar toda la CPU y la memoria disponibles.

Para una perspectiva de software, escriba una tarea privilegiada que ocasionalmente, de forma aleatoria, invierta bits en su código, y vea cómo lidia con eso. Ese es tu simulador.

En cuanto al hardware, las piezas serán viejas, porque se necesita mucho tiempo para que algo se clasifique en el espacio. Además, las partes nuevas se están reduciendo de tamaño continuamente, y cuanto más pequeña es una característica (piense en la celda de memoria en un I.C.), más susceptible es a la corrupción de un evento de radiación.

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

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

Tuvimos una prueba de caminar y ceros de TODOS los registros. ¡Eso incluía el contador del programa!

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

Es probable que parte de esto no esté relacionado con los programas en el espacio, pero le da una idea de la magnitud de la comprobación que es posible.

Creo que cuanto peor es el entorno, más se utiliza Códigos de corrección de errores , y hay < a href="http://en.wikipedia.org/wiki/Dynamic%5Frandom%5Faccess%5Fmemory#Errors%5Fand%5Ferror%5Fcorrection"> memorias ECC que se pueden usar en cierta medida.

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 paneles de investigación.
• La memoria dinámica no es buena para los sistemas integrados. Problemas de confiabilidad.

Supongo que el software ECC de datos y el uso de la teoría de la información y un alojamiento personalizado para difundir los datos en todo el sistema para administrar los fallos de memoria serían un comienzo. Pero no estudio el software Rad-Hard, así que no estoy familiarizado con él, eso es solo una suposición.