In cosa è integrato il software Mars Curiosity Rover?

Il rover Mars Curiosity è atterrato con successo e uno dei video promozionali "7 minuti di terrore" si vanta che ci siano 500.000 righe di codice. È un problema complicato, senza dubbio. Ma questo è un sacco di codice, sicuramente c'era un grande sforzo di programmazione dietro di esso. Qualcuno sa qualcosa su questo progetto? Posso solo immaginare che sia una specie di C. incorporato

Funziona con 2,5 milioni di linee di C su un processore RAD750 prodotto da BAE . La JPL ha un po 'più di informazioni ma sospetto che molti dei dettagli non siano pubblicizzati. Sembra che gli script di test siano stati scritti in Python.

Il sistema operativo sottostante è VxWorks RTOS di Wind River . L' 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 da estensioni. Wind River fornisce un'enorme quantità di dettagli su come e perché VxWorks .

Il chipset sottostante è quasi assurdamente robusto . Le sue specifiche potrebbero non sembrare molto all'inizio, ma può avere un solo "schermo blu" ogni 15 anni. Ricorda, questo è sotto il bombardamento da radiazioni che ucciderebbero un essere 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 parla delle caratteristiche dei computer e della base di codice su Curiosity.

Il codice si basa su quello di MER ( Spirit and Opportunity ), basato sul loro primo lander, MPF ( Sojourner ). Sono 3,5 milioni di linee di C (in gran parte autogenerate), in esecuzione su un processore RA50 prodotto da BAE e dal sistema operativo VxWorks . Oltre un milione di righe sono state codificate a mano.

Il codice è implementato come 150 moduli separati, ciascuno con una funzione diversa. I moduli altamente accoppiati sono organizzati in componenti che astraggono i moduli in essi contenuti e "specificano una funzione, un'attività o un comportamento specifici". Questi componenti sono ulteriormente organizzati in livelli e non ci sono "non più di 10 componenti di livello superiore".

Fonte: Keynote talk di Benjamin Cichy al 2010 Workshop on Spacecraft Flight Software (FSW-10) , diapositive, audio e video (inizia con una panoramica della missione, discussione sull'architettura nella diapositiva 80).

Qualcuno su Hacker News ha chiesto "Non sono sicuro di cosa significhi che la maggior parte del codice C viene generata automaticamente. Da cosa?"

Non ne sono sicuro al 100%, sebbene probabilmente ci sia una presentazione separata in quell'anno o in un altro anno che descriva il loro processo di generazione automatica. So che è stato un argomento popolare in generale alla conferenza FSW-11.

Simulink è una possibilità. È un componente MATLAB popolare tra gli ingegneri meccanici, e quindi la maggior parte degli ingegneri di navigazione e controllo, e consente loro di "codificare" e simulare le cose senza pensare che stiano codificando.

La programmazione basata su modelli è sicuramente una cosa di cui l'industria sta lentamente prendendo coscienza, ma non so quanto stia prendendo piede in JPL o se avrebbero scelto di usarla quando il progetto è iniziato.

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, ricevere la telemetria dal software di volo ed elaborarlo con il software di terra. Ogni pacchetto di comando / telemetria è una struttura di dati eterogenea ed è necessario che entrambi i lati funzionino dalla stessa identica definizione di pacchetto e formattare il pacchetto in modo che sia formattato correttamente da un lato e analizzato dall'altro lato. Ciò implica che molte cose vadano bene, incluso il tipo di dati, le dimensioni e l'endianness (anche se quest'ultima è generalmente una cosa globale; potresti avere più processori a bordo con endianness diverse).

Ma questa è solo la superficie. È necessario un sacco di codice ripetitivo su entrambi i lati per gestire elementi quali registrazione, convalida comando / telemetria, controllo dei limiti e gestione degli errori. E poi puoi fare cose più sofisticate. Supponi di avere un comando per impostare un valore del registro hardware e che il valore venga inviato di nuovo in telemetria in un pacchetto specifico. È possibile generare software di terra che monitora quel punto di telemetria per garantire che quando questo valore di registro è impostato, alla fine la telemetria cambia per riflettere la modifica. E, naturalmente, alcuni punti di telemetria sono più importanti di altri (ad es. La corrente principale del bus) e sono designati per scendere in più pacchetti, il che comporta una copia extra sul lato volo e la de-duplicazione dei dati sul lato terra.

Con tutto ciò, è molto più facile (secondo me) scrivere una raccolta di file di testo statici (in XML, CSV o alcuni 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 nel video, con una sola eccezione. Ho sentito che il codice C generato automaticamente è scritto da script Python e la quantità di codifica automatica in un progetto varia notevolmente a seconda di chi sia il lead FSW.