Hai affrontato la tempra spaziale?

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

Alcune piccole differenze che vengono in mente al momento sono:

• Estremamente orientato al processo.
• Il software spaziale avrà sempre timer software e watchdog hardware.
• Ogni sistema spaziale su cui ho lavorato era un sistema in tempo reale difficile.
• Simuli (con grande precisione) ogni attore esterno al sistema. Questo di solito comporta la creazione di hardware personalizzato (a volte molto costoso) che viene utilizzato esclusivamente per il test.
• Spendi enormi sforzi e spese facendo test formali.
• Il cliente (di solito JPL) è estremamente coinvolto nel processo di test.
• In genere stai utilizzando compilatori e ambienti di sviluppo vecchi e conosciuti, piuttosto che nuovi.
• recensioni di codici, recensioni di codici e recensioni di codici.
• È meglio che tu stia passando facilmente dal mondo dell'hardware a quello del software. 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 è masterizzata in ROM. Questo non cambierà mai. Gli altri 2 sono per la versione corrente e la prossima / ultima versione.
• L'analisi dei guasti (MTBF) è molto 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 in seguito quando si chiamava Draper Lab durante la "guerra fredda".

Per il computer di guida di Apollo, il nucleo è stato utilizzato per la RAM e per la ROM è stato utilizzato uno speciale nucleo intrecciato. La macchina stessa è stata realizzata interamente con gate NOR ed è stata sincronizzata abbastanza lentamente, per affidabilità.

Non ho lavorato direttamente sui missili Minuteman, ma ero a conoscenza di alcuni dei problemi. Se una testata nucleare si spegne nelle vicinanze di alcuni dispositivi elettronici, in pratica lo mette in corto. Il computer di guida aveva un sensore di radiazioni che avrebbe spento immediatamente Vc in modo da non bruciare nulla. Quindi il computer si riavvierà, dopo che i suoi registri sono stati cancellati.

Per gestirlo, il computer avrebbe periodicamente eseguito l'istantanea dei suoi registri nel core e, al riavvio, si sarebbe avviato da quel checkpoint. Per farlo funzionare, il software (tutto in ASM) doveva essere analizzato per vedere che poteva prendere qualsiasi numero di tali colpi, a qualsiasi frequenza, senza ottenere risposte sbagliate. Era chiamato "riavviato protetto". Problema molto interessante, dato che (grazie al cielo) non ha mai dovuto essere usato.

Per ottenere un'affidabilità dell'ambiente particolarmente specifica in C, ecco alcune cose veramente concrete che ho visto fare.

MISRA-C: il sottosistema C automobilistico. Un po 'come Ravenscar ADA / Java.

watchdog: assicurati che il programma non si blocchi

memoria ecc (a volte)

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

1) checksum del programma in modo continuo (era in EPROM ma ha ancora bit girati).

2) checksum certe strutture di dati periodicamente.

3) Controlli di integrità della CPU periodicamente.

4) controlla che i registri IO abbiano ciò che dovrebbero avere in loro.

4b) legge le uscite su ingressi indipendenti e verifica.

Molto più importanti del linguaggio di programmazione sono i requisiti del sistema sottostante (OS e Hardware). Fondamentalmente, è necessario garantire (e dimostrare) un comportamento deterministico e prevedibile del sistema generale. Molte ricerche correlate sono state fatte nella comunità in tempo reale. Consiglio vivamente di leggere due libri se si vuole veramente studiare questo argomento: Sistemi in tempo reale di Jane Liu e un libro con lo stesso nome Hermann Kopetz . Il primo copre la pianificazione in modo molto teorico mentre il secondo riporta i piedi a terra e copre praticamente tutti gli aspetti correlati della progettazione del sistema (in tempo reale), ad es. tolleranza d'errore.

Inoltre, i seguenti due episodi illustrano in modo chiaro la qualità dei problemi che i tecnici software devono affrontare quando inviano qualcosa nello spazio:

• Ariane 5 (riutilizzo di software collaudato con 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 laboratorio per software affidabile (LaRS) presso il laboratorio Jet Propulsion .

Ecco un riepilogo delle regole documentate:

1. Conformità linguistica

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

2. Esecuzione prevedibile

   • Utilizza limiti di loop verificabili per tutti i loop destinati a terminare.
   • Non utilizzare la ricorsione diretta o indiretta.
   • Non utilizzare l'allocazione dinamica della memoria dopo l'inizializzazione dell'attività.
   • * Utilizza i messaggi IPC per la comunicazione delle attività.
   • Non utilizzare i ritardi delle attività per la sincronizzazione delle attività.
   • * Trasferisci esplicitamente permesso di scrittura (proprietà) per oggetti dati condivisi.
   • Posizionare restrizioni sull'uso di semafori e serrature.
   • Usa la protezione della memoria, i margini di sicurezza, i modelli di barriera.
   • Non utilizzare goto, setjmp o longjmp.
   • Non utilizzare assegnazioni di valori selettivi a elementi di una lista di enum.

3. Coding difensivo

   • Dichiarare gli oggetti dati al livello di ambito più piccolo possibile.
   • Controllare il valore restituito delle funzioni non vuote o eseguire il cast esplicito su (void).
   • Verifica la validità dei valori passati alle funzioni.
   • Utilizza asserzioni statiche e dinamiche come controlli di integrità.
   • * Usa U32, I16, ecc. anziché i tipi di dati C predefiniti come int, short, ecc.
   • Rendi esplicito l'ordine di valutazione nelle espressioni composte.
   • Non usare espressioni con effetti collaterali.

4. Code Clarity

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

*) Tutte le regole sono devono regole, ad eccezione di quelle contrassegnate con un asterisco.

I sistemi di calcolo a prova di spazio sono tutti basati sull'affidabilità. Una profonda introduzione al campo può essere trovata in Concetti fondamentali di affidabilità di Algirdas Avižienis, Jean-Claude Laprie & Brian Randell.

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

Per dare un senso pragmatico delle sfide dello spazio, pensa a:

• condizioni estreme nello spazio: molto calde quando orientate verso il sole, molto fredde dall'altra parte, molti raggi cosmici che possono capovolgere i bit in memoria, enormi accelerazioni e vibrazioni quando vengono lanciati, ... Hardware per lo spazio deve essere molto più robusto dell'hardware per i militari.

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

Quello che ho imparato da un progetto sono stato coinvolto come stagista:

Le tue specifiche hardware cambieranno, di solito in peggio!

Ad esempio, è stata promessa la CPU indurita nello spazio utilizzata nel progetto, promesso , attenzione, che funzionerebbe a 20 MHz.

Il risultato finale è stato eseguito a 12 MHz. Il programmatore senior del progetto ha dedicato molto tempo alla riprogettazione degli algoritmi per soddisfare i rigidi requisiti in tempo reale dei sistemi di controllo e gran parte del software di telemetria è stato scaricato su un secondo sistema anziché funzionare sulla CPU primaria.

Quindi, prova a lasciare alcune risorse extra disponibili nel design originale e prova a non utilizzare tutte le 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 scopri come si comporta. Questo è il tuo simulatore.

Dal punto di vista dell'hardware, le parti saranno obsolete, perché ci vuole molto tempo per ottenere qualcosa che sia classificato come spazio. Inoltre, le nuove parti si restringono continuamente di dimensioni, e più piccola è una caratteristica (si pensi alla cella di memoria su un I.C.) più è suscettibile alla corruzione da un evento di radiazione.

Ho lavorato su un dispositivo di sicurezza fondamentale e abbiamo dovuto passare attraverso alcuni circuiti simili.

Abbiamo avuto variabili critiche per la sicurezza. C'era una copia dell'inverso della variabile. Dopo ogni ciclo, la variabile è stata confrontata con la sua inversa.

Abbiamo avuto un test a zeri e a piedi di TUTTI i registri. Questo includeva il contatore del programma!

Abbiamo fatto un test di tutti gli opcode del set di microistruzione. Dovevamo essere sicuri che se avessi aggiunto 2 registri, i registri sono stati aggiunti.

Probabilmente questo non è legato ai programmi nello spazio, ma ti dà un'idea della grandezza del controllo che è possibile.

Credo che peggio sia un ambiente più è usato Error Correcting Code , e c'è < a href="http://en.wikipedia.org/wiki/Dynamic%5Frandom%5Faccess%5Fmemory#Errors%5Fand%5Ferror%5Fcorrection"> memorie ECC che possono essere utilizzate in una certa misura.

Se è possibile stimare il livello di errori, è possibile costruire un codice di correzione degli errori in grado di gestire gli errori introdotti.

• Sì, la memoria di base è nelle schede di ricerca.
• La memoria dinamica non è buona per i sistemi embedded. Problemi di affidabilità.

Direi che l'ECC software dei dati e l'utilizzo della teoria delle informazioni e di un sistema di allerta personalizzato per diffondere i dati nel sistema per gestire i guasti della memoria sarebbe un inizio. Ma, non studio software rad-hard quindi non ho familiarità con esso, è solo una supposizione.