Il Mars Curiosity rover è atterrato con successo, e uno dei video promozionali "7 minuti di terrore "vanta circa 500.000 linee di codice. È un problema complicato, senza dubbio. Ma questo è un sacco di codice, sicuramente c'è stato un grande sforzo di programmazione dietro di esso. Qualcuno sa qualcosa su questo progetto? Posso solo immaginare che sia una specie di C incorporato.
È in esecuzione 2,5 milioni di righe di C su un Processore RAD750 prodotto da BAE . Il JPL ha un po 'più di informazioni ma sospetto che molti dettagli non siano pubblicizzati. Sembra che gli script di test siano stati scritti in Python.
Il sistema operativo sottostante è Wind River VxWorks RTOS . Il RTOS in questione può essere programmato in C, C ++, Ada o Java. Tuttavia, solo C e C ++ sono standard per il sistema operativo, Ada e Java sono supportati dalle estensioni. Wind River fornisce un'enorme quantità di dettagli sul come e i perché di VxWorks .
Il chipset sottostante è quasi assurdamente robusto. Le sue specifiche potrebbero non sembrare molto all'inizio, ma è consentito avere uno e un solo "schermo blu" ogni 15 anni. Tenete a mente, questo è sotto bombardamento da radiazioni che ucciderebbero un umano molte volte. Nello spazio, la robustezza vince sulla velocità. Naturalmente, la robustezza del genere ha un costo. In questo caso, è un bel $ 200.000 a $ 500.000.
Un programmatore di Erlang talk sulle funzionalità dei computer e del codice base su Curiosity.
Il codice è basato su quello di MER ( Spirit e Opportunity ), che erano basati sul loro primo lander, MPF ( Sojourner ). Sono 3,5 milioni di righe di C (in gran parte autogenerate), eseguite su un processore RA50 prodotto da BAE e VxWorks sistema operativo. Oltre un milione di righe sono state codificate a mano.
Il codice è implementato come 150 moduli separati, ognuno con una funzione diversa. I moduli altamente accoppiati sono organizzati in componenti che astraggono i moduli che contengono e "specificano una funzione specifica, un'attività o un comportamento". Questi componenti sono ulteriormente organizzati in livelli e non ci sono "non più di 10 componenti di primo livello."
Fonte: Keynote talk di Benjamin Cichy a 2010 Workshop su Spacecraft Flight Software (FSW-10) , diapositive, audio e video (inizia con la panoramica delle missioni, discussione sull'architettura alla diapositiva 80).
Qualcuno su Hacker News ha chiesto "Non sono sicuro che cosa significa che la maggior parte del codice C viene generata automaticamente. Da cosa?"
Non sono sicuro al 100%, anche se probabilmente c'è una presentazione separata in quell'anno o un anno diverso che descrive il loro processo di generazione automatica. So che è stato un argomento molto popolare in generale alla conferenza FSW-11.
Simulink è una possibilità. È un componente MATLAB popolare tra gli ingegneri meccanici, e quindi la maggior parte della navigazione e dell'amplificazione; i tecnici di controllo e consente loro di 'codificare' e simulare le cose senza pensare che stiano codificando.
La programmazione basata su modelli è sicuramente una cosa a cui l'industria sta lentamente diventando consapevole, ma non so quanto stia prendendo piede a JPL o se avrebbero scelto di usarlo all'avvio del progetto.
La terza e più probabile possibilità è per il codice di comunicazione. Con tutti i sistemi spaziali, è necessario inviare comandi al software di volo dal software di terra e ricevere telemetria dal software di volo ed elaborarlo con il software di terra. Ogni pacchetto di comandi / telemetria è una struttura di dati eterogenea ed è necessario che entrambe le parti stiano funzionando dalla stessa identica definizione di pacchetto e formatta il pacchetto in modo che sia formattato correttamente su un lato e analizzato dall'altro lato. Ciò comporta l'ottenimento di un sacco di cose giuste, inclusi il tipo, la dimensione e l'endianness dei dati (sebbene quest'ultimo sia di solito una cosa globale, potresti avere più processori a bordo con endianness diversi).
Ma questa è solo la superficie. È necessario un sacco di codice ripetitivo su entrambi i lati per gestire operazioni quali la registrazione, la convalida di comandi / telemetria, il controllo dei limiti e la gestione degli errori. E poi puoi fare cose più sofisticate. Supponiamo che tu abbia un comando per impostare un valore di registro hardware e che quel valore sia rinviato nella telemetria in un particolare pacchetto. È possibile generare software di terra che monitora quel punto di telemetria per garantire che quando viene impostato questo valore di registro, alla fine la telemetria cambi per riflettere la modifica. E, naturalmente, alcuni punti di telemetria sono più importanti di altri (ad esempio la corrente del bus principale) e sono designati per scendere in più pacchetti, il che comporta una copia aggiuntiva sul lato volo e la deduplicazione dei dati sul lato terreno.
Con tutto ciò, è molto più semplice (a mio parere) scrivere una raccolta di file di testo statici (in XML, CSV, o qualche DSL / what-have-you), eseguirli attraverso uno script Perl / Python, e presto! Codice!
Non lavoro in JPL, quindi non posso fornire alcun dettaglio che non sia presente nel video, con un'eccezione. Ho sentito che il codice C generato automaticamente è scritto da script Python, e la quantità di autocodifica in un progetto varia molto a seconda di chi è il lead di FSW.
Leggi altre domande sui tag history embedded-systems space-technology