Hai affrontato l'indurimento dello spazio?

Sono molto ansioso di studiare le migliori pratiche quando si tratta di indurimento dello spazio. Ad esempio, ho letto (anche se non riesco più a trovare l'articolo) che alcune parti fondamentali dei rover Mars non utilizzavano l'allocazione dinamica della memoria, in realtà era vietato. Ho anche letto che la memoria di base vecchio stile potrebbe essere preferibile nello spazio.

Stavo guardando alcuni dei progetti associati a Google Lunar Challenge e mi chiedevo come sarebbe stato ottenere il codice sulla luna, o anche solo nello spazio. So che le schede temprate nello spazio offrono un po 'di sanità mentale in un ambiente così duro, tuttavia mi chiedo (come programmatore C) come avrei bisogno di modificare il mio pensiero e il mio codice se stavo scrivendo qualcosa che sarebbe eseguito nello spazio?

Penso che i prossimi anni potrebbero mostrare una maggiore crescita nelle società spaziali private, mi piacerebbe davvero essere almeno un po 'ben informato sulle migliori pratiche.

Cosa succede a un programma se radiazioni, freddo o calore bombardano una tavola che ha subito danni al suo isolamento? Penso che l'obiettivo sia mantenere gli umani all'interno di un'astronave (per quanto riguarda la riparazione o lo scambio di cose) ed evitare le missioni per sistemare le cose.

Inoltre, se la scheda mantiene un sistema critico, i primi avvisi sembrano fondamentali.

Come si può fare esperienza in questo attraverso test, prove ed errori (salvo il lancio del proprio satellite personale?)

Il software spaziale non è una magia arcana. Stai ancora utilizzando 0 e 1, non 1 e 3. Quindi probabilmente non c'è nessun fattore wow coinvolto nella descrizione di ciò che accade nello sviluppo di software.

Alcune lievi differenze che vengono in mente al momento sono:

• Estremamente orientato al processo.
• Il software spaziale avrà sempre timer di controllo sia hardware che software.
• Ogni sistema spaziale su cui ho lavorato era un sistema difficile in tempo reale.
• Simuli (con grande precisione) ogni attore esterno al sistema. Questo di solito comporta la costruzione di hardware personalizzato (a volte molto costoso) che viene utilizzato esclusivamente per i test.
• Spendi enormi sforzi e spese nel fare test formali.
• Il cliente (di solito JPL) è estremamente coinvolto nel processo di test.
• In genere si utilizzano compilatori e ambienti di sviluppo vecchi e noti, anziché quelli nuovi.
• Revisioni del codice, recensioni del codice e recensioni del codice.
• Farai meglio a passare da un mondo hardware a un altro. Non devi sapere come progettare l'hardware ma devi sapere come funziona.
• Ampio uso di apparecchiature di prova, come oscilloscopi, analizzatori logici, sintetizzatori e analizzatori di spettro.
• Almeno 3 posizioni per la memorizzazione del programma applicativo. L'impostazione predefinita viene masterizzata nella ROM. Questo non cambierà mai. Gli altri 2 sono per la versione corrente e la prossima / ultima versione.
• L'analisi dei guasti (MTBF) è davvero importante.
• Sistemi ridondanti e piani di failover per i componenti critici.

Mi sono appena imbattuto nella tua domanda interessante.

Ero al Instrumentation Lab durante Apollo, e di nuovo più tardi quando fu chiamato Draper Lab durante la "guerra fredda".

Per il computer di guida Apollo, il core è stato utilizzato per la RAM e uno speciale core intrecciato è stato utilizzato per la ROM. La macchina stessa era interamente realizzata con cancelli NOR ed era abbastanza lenta, per affidabilità.

Non ho lavorato direttamente sui missili Minuteman, ma ero a conoscenza di alcuni dei problemi. Se una testata nucleare si spegne in prossimità di alcuni componenti elettronici, sostanzialmente lo cortocircuita. Il computer di guida aveva un sensore di radiazioni che spegneva istantaneamente Vc in modo da non bruciare nulla. Quindi il computer si riavvierebbe, avendo cancellato i suoi registri.

Per gestirlo, il computer avrebbe periodicamente snapshot i suoi registri nel core e, al suo riavvio, si sarebbe avviato da quel punto di controllo. Per far funzionare tutto questo, il software (tutto in ASM) ha dovuto essere analizzato per vedere che poteva prendere un numero qualsiasi di tali hit, a qualsiasi frequenza, senza ottenere risposte sbagliate. Quello era chiamato "riavvio protetto". Problema molto interessante, dato che (meno male) non ha mai dovuto essere usato.

Per ottenere la massima affidabilità ambientale, in particolare in C, ecco alcune cose davvero concrete che ho visto fare.

MISRA-C: il sottoinsieme C Automotive. Un po 'come Ravenscar ADA / Java.

cani da guardia: assicurarsi che il programma non si blocchi

ecc memory (a volte)

checksum: alla ricerca di bit lancianti. Ho visto tutti e tre questi in un unico sistema:

1) esegue il checksum del programma continuamente (era in EPROM ma aveva ancora i bit capovolti).

2) eseguire il checksum periodicamente di determinate strutture di dati.

3) Controlli di integrità della CPU periodicamente.

4) verifica che i registri IO abbiano ciò che dovrebbero avere in essi.

4b) rileggere le uscite su ingressi indipendenti e verificare.

Molto più importanti del linguaggio di programmazione sono i requisiti del sistema sottostante (sistema operativo e hardware). Fondamentalmente, è necessario garantire (e dimostrare) un comportamento deterministico e prevedibile dell'intero sistema. Molte ricerche correlate sono state condotte nella comunità in tempo reale. Consiglio vivamente di leggere due libri se vuoi davvero studiare questo argomento: Real-Time Systems di Jane Liu e un libro con lo stesso nome di Hermann Kopetz . Il primo copre la programmazione in modo molto teorico mentre il secondo riporta i piedi per terra e praticamente copre tutti gli aspetti correlati della progettazione del sistema (in tempo reale), ad esempio la tolleranza agli errori.

Inoltre, i seguenti due incidenti illustrano bene la qualità dei problemi che gli ingegneri del software devono affrontare quando inviano qualcosa nello spazio:

• Ariane 5 (Riutilizzo di software collaudato sotto diversi vincoli)
• Mars Rover Pathfinder Reboot (inversione di priorità)

Ho trovato questo documento (circa 2009) per lo standard di codifica istituzionale JPL per il linguaggio di programmazione C sul Laboratory for Reliable Software (LaRS) nel sito del Jet Propulsion Laboratory .

Ecco un riassunto delle regole documentate:

1. Conformità linguistica

   • Non allontanarti dalla definizione della lingua.
   • Compila con tutti gli avvisi abilitati; utilizzare analizzatori di codice sorgente statici.

2. Esecuzione prevedibile

   • Utilizzare i limiti di loop verificabili per tutti i loop che si intende terminare.
   • Non utilizzare la ricorsione diretta o indiretta.
   • Non utilizzare l'allocazione dinamica della memoria dopo l'inizializzazione dell'attività.
   • * Utilizzare i messaggi IPC per la comunicazione delle attività.
   • Non utilizzare i ritardi delle attività per la sincronizzazione delle attività.
   • * Trasferisci esplicitamente l'autorizzazione alla scrittura (proprietà) per oggetti di dati condivisi.
   • Porre restrizioni sull'uso di semafori e lucchetti.
   • Utilizzare la protezione della memoria, i margini di sicurezza, i modelli di barriera.
   • Non usare goto, setjmp o longjmp.
   • Non utilizzare assegnazioni di valori selettivi agli elementi di un elenco enum.

3. Codifica difensiva

   • Dichiarare gli oggetti dati al più piccolo livello possibile di ambito.
   • Controllare il valore di ritorno delle funzioni non nulle o esplicitamente cast su (nullo).
   • Verificare la validità dei valori passati alle funzioni.
   • Usa asserzioni statiche e dinamiche come controlli di integrità.
   • * Usa U32, I16, ecc. Invece di tipi di dati C predefiniti come int, short, ecc.
   • Rendere esplicito l'ordine di valutazione nelle espressioni composte.
   • Non usare espressioni con effetti collaterali.

4. Chiarezza del codice

   • Fai un uso molto limitato del pre-processore C.
   • Non definire macro all'interno di una funzione o di un blocco.
   • Non indefinire o ridefinire le macro.
   • Inserisci #else, #elif e #endif nello stesso file del #if o #ifdef corrispondenti.
   • * Non inserire più di una dichiarazione o dichiarazione per riga di testo.
   • * Utilizzare funzioni brevi con un numero limitato di parametri.
   • * Utilizzare non più di due livelli di riferimento indiretto per dichiarazione.
   • * Utilizzare non più di due livelli di dereferenziazione per riferimento all'oggetto.
   • * Non nascondere le operazioni di dereference all'interno di macro o typedef.
   • * Non utilizzare puntatori a funzioni non costanti.
   • Non trasmettere i puntatori a funzione in altri tipi.
   • Non inserire codice o dichiarazioni prima di una direttiva #include.

*) Tutte le disposizioni sono devono regole, ad eccezione di quelli contrassegnati con un asterisco.

I sistemi informatici a prova di spazio si basano sull'affidabilità. Una profonda introduzione al campo può essere trovata nei concetti fondamentali di affidabilità di Algirdas Avižienis, Jean-Claude Laprie e Brian Randell.

Il tempo reale è anche un concetto chiave per lo spazio informatico. Come Pankrat, consiglierei Real-Time Systems di Hermann Kopetz.

Per dare un senso pragmatico delle sfide dell'informatica spaziale, pensa a:

• condizioni estreme nello spazio: molto calde se orientate verso il sole, molto fredde dall'altra parte, molti raggi cosmici che possono invertire bit in memoria, enormi accelerazioni e vibrazioni durante il lancio, ... L'hardware per lo spazio deve essere molto più robusto dell'hardware per militari.

• Quando si verifica un guasto, tranne nella Stazione Spaziale Internazionale o per il Telescopio Spaziale Hubble, nessuno arriva e sostituisce il sistema guasto. Tutto deve essere riparato da terra attraverso la massima osservabilità e comandabilità e attraverso sistemi di riserva a cui passare. Questo è facile per i satelliti terrestri. Ciò è più difficile con le sonde spaziali per le quali i ritardi di comunicazione possono durare un'ora. In effetti, tutto deve essere il più affidabile possibile in primo luogo.

Cosa ho imparato dall'unico progetto in cui sono stato coinvolto come stagista:

Le tue specifiche hardware cambieranno, di solito in peggio!

Ad esempio, è stato promesso, promesso , la CPU indurita per lo spazio che veniva utilizzata nel progetto , che funzionerebbe a 20 MHz.

Il risultato finale ha funzionato a 12 MHz. Il programmatore senior del progetto ha impiegato molto tempo a ridisegnare gli algoritmi per soddisfare i requisiti in tempo reale dei sistemi di controllo e gran parte del software di telemetria è stato scaricato su un secondo sistema invece di essere eseguito sulla CPU primaria.

Quindi, prova a lasciare alcune risorse extra disponibili nel design originale e cerca di non utilizzare tutta la CPU e la memoria disponibili.

Per una prospettiva software, scrivi un'attività privilegiata che occasionalmente, in modo casuale, capovolge i bit nel tuo codice e vedi come risolverlo. Questo è il tuo simulatore.

Per quanto riguarda l'hardware, le parti saranno vecchie, perché ci vuole molto tempo per ottenere qualcosa che sia classificato nello spazio. Inoltre, le nuove parti si riducono continuamente di dimensioni e più una caratteristica è piccola (si pensi alla cella di memoria su un circuito integrato) più è sensibile alla corruzione da un evento di radiazione.

Ho lavorato su un dispositivo critico per la sicurezza e abbiamo dovuto passare attraverso alcuni cerchi simili.

Avevamo variabili critiche per la sicurezza. C'era una copia dell'inverso della variabile. Dopo ogni ciclo, la variabile è stata verificata rispetto al suo inverso.

Abbiamo fatto un test a piedi e zeri su TUTTI i registri. Ciò includeva il contatore del programma!

Abbiamo testato tutti i codici operativi del set di micro istruzioni. Dovevamo essere sicuri che se si aggiungessero 2 registri, sarebbero stati aggiunti i registri.

Parte di questo probabilmente non è correlata ai programmi nello spazio, ma ti dà un'idea dell'entità del controllo che è possibile.

Credo che peggio sia un ambiente, più codici di correzione errori vengono utilizzati e ci sono memorie ECC che possono essere utilizzate in una certa misura.

Se si può stimare il livello di errori, si può costruire un codice di correzione degli errori in grado di gestire gli errori introdotti.

• Sì, la memoria principale è nei forum di ricerca.
• La memoria dinamica non è buona per i sistemi integrati. Problemi di affidabilità.

Immagino che il software ECC dei dati e l'utilizzo della teoria dell'informazione e di una memoria personalizzata per diffondere i dati nel sistema per gestire gli errori di memoria sarebbe un inizio. Ma non studio software rad-hard, quindi non ne ho familiarità, è solo una supposizione.