A pochi minuti dall’allunaggio, il computer di Apollo 11 lanciò un allarme. Sul display comparve un numero: 1202. Armstrong e Aldrin scendevano verso la Luna; un errore poteva trasformare l’impresa del secolo in un cratere. Il software, invece, scelse quali operazioni salvare, scartò le altre e continuò a guidare la discesa. L’uomo arrivò sulla Luna anche perché una macchina aveva imparato a riconoscere le priorità.
È da quell’istante che conviene raccontare la storia del software spaziale. Dalla capacità di prendere la decisione giusta nel momento peggiore. Da Apollo alle sonde Voyager, dallo Space Shuttle ai rover marziani fino all’elicottero Ingenuity, l’evoluzione dei computer di bordo non è stata una gara a chi possedeva più memoria. È stata una lunga trattativa con l’imprevisto. Oggi cambia anche l’economia dello spazio.
Indice degli argomenti
Apollo 11 e la nascita del software spaziale
Nel 1969 l’Apollo Guidance Computer disponeva di 2.048 parole di memoria riscrivibile e 36.864 parole di memoria fissa: circa 4 e 72 kilobyte, secondo la rappresentazione convenzionale a parole da 16 bit. La memoria fissa era una core rope memory: fili intrecciati attraverso nuclei magnetici trasformavano il programma in materia. Scrivere il software significava, in parte, trasformarlo in un oggetto fisico.
Al MIT, il gruppo guidato da Margaret Hamilton sviluppò un principio decisivo: non tutte le attività hanno la stessa urgenza. L’esecutivo asincrono assegnava priorità ai processi e, in caso di sovraccarico, poteva interrompere operazioni secondarie senza perdere quelle indispensabili alla navigazione. Gli allarmi 1201 e 1202 segnalavano un problema, non una sconfitta. La lezione è rimasta: un software affidabile non è quello che promette di non incontrare mai errori, ma quello che sa attraversarli senza perdere il controllo.
Voyager e gli aggiornamenti oltre i confini di casa
Nel 1977 partirono Voyager 1 e Voyager 2. Nessuna potenza paragonabile a quella di un telefono moderno. Su ciascuna sonda operavano sei computer, due per ognuna delle tre funzioni principali: comandi, dati di volo e controllo d’assetto. NASA indica un totale di circa 32 mila parole di memoria, equivalenti grossomodo a 68 kilobyte. La ridondanza offriva vie d’uscita ai guasti.
Il dettaglio più vertiginoso è arrivato molto dopo il lancio. Nel 2024 Voyager 1 cominciò a ritrasmettere dati leggibili dopo mesi di anomalie: un chip di memoria danneggiato aveva compromesso parte del software del Flight Data System. Gli ingegneri riorganizzarono da remoto il codice su un apparato precedente al personal computer. Da una Terra lontanissima, correggere pochi frammenti di programma significava recuperare la voce di una sonda interstellare. La space economy comincia anche qui: mantenere un asset operativo per decenni.
Ridondanza e tempo reale nei computer di bordo
Con il primo volo dello Space Shuttle, nel 1981, l’informatica di bordo cambiò scala. Il veicolo aveva cinque computer general purpose IBM: quattro operavano in sincronia nelle fasi più delicate e confrontavano continuamente i risultati; il quinto ospitava un Backup Flight System con software sviluppato separatamente. Più computer identici isolavano i guasti hardware. Codice diverso, scritto da un altro gruppo, riduceva il rischio di un difetto comune.
Per il software primario venne utilizzato HAL/S, un linguaggio progettato per l’avionica spaziale. Il vero salto era architetturale: sincronizzazione, votazione, separazione delle funzioni, recupero. La sicurezza nasceva dalla collaborazione fra sistemi imperfetti, non da un computer infallibile.
Mars Pathfinder e il bug del tempo reale
Nel 1997 Mars Pathfinder sbarcò su Marte con un computer basato sul processore RAD6000 e il sistema operativo real-time VxWorks. Ora bisognava coordinare attività concorrenti entro scadenze rigidissime. A volte la priorità dichiarata di un processo non coincide con quella che riesce davvero a ottenere.
Pathfinder subì alcuni riavvii legati a un caso di priority inversion: un’attività poco urgente tratteneva una risorsa necessaria a un compito più importante, mentre altri processi ne ostacolavano l’esecuzione. Il difetto fu riprodotto in laboratorio e corretto da remoto. La missione dipendeva da come il software distribuiva pochi istanti di CPU. Nello spazio, «tempo reale» non significa semplicemente veloce: significa arrivare esattamente quando serve.
Dai rover a Ingenuity: l’autonomia del codice su Marte
Curiosity, arrivato su Marte nel 2012, ha portato questa disciplina dentro una macchina scientifica mobile. Con processori RAD750 resistenti alle radiazioni e VxWorks, governa strumenti, energia, mobilità e protezioni. Nella discesa con sky crane non c’era spazio per un pilota remoto: il segnale dalla Terra arrivava troppo tardi.
Con Perseverance il passaggio è diventato ancora più evidente. Il sistema AutoNav costruisce rappresentazioni tridimensionali del terreno, valuta ostacoli e pianifica passaggi sicuri verso obiettivi definiti dagli operatori. Nel 2026 NASA ha illustrato anche Mars Global Localization, una tecnologia che consente al rover di affinare autonomamente la propria posizione confrontando ciò che vede con mappe ricavate dall’orbita. Gli uomini fissano obiettivi e vincoli; il rover non aspetta più istruzioni per ogni metro. L’autonomia trasforma il tempo delle comunicazioni, prima un ostacolo, in un parametro da progettare.
Ingenuity, F Prime e il software aperto
Il 19 aprile 2021 Ingenuity si sollevò dalla superficie marziana. Era il primo volo controllato a motore nell’atmosfera di un altro pianeta. Il piccolo elicottero usava anche un processore commerciale della famiglia Snapdragon e il framework di software di volo open source F Prime, sviluppato al Jet Propulsion Laboratory. Riutilizzo, test e interfacce comuni accelerano lo sviluppo.
L’esperimento doveva completare fino a cinque voli. Ne realizzò 72 prima che un danno alle pale, durante l’atterraggio del gennaio 2024, ponesse fine alle operazioni di volo. I comandi arrivavano dalla Terra; stabilizzazione e navigazione in volo avvenivano a bordo. Autonomia, miniaturizzazione e codice riusabile aprivano così nuove classi di missioni.
L’industria del software spaziale tra open source e certificazione
L’industria commerciale deve ridurre costi e tempi di sviluppo. I sistemi moderni, dalle capsule Dragon ai lanciatori riutilizzabili e ai piccoli satelliti, combinano elaborazione a bordo, automazione e architetture ridondanti. Linux e C++, nelle applicazioni spaziali che li adottano, raccontano la contaminazione crescente con l’informatica terrestre. Ma Dragon, Ingenuity e rover NASA hanno requisiti, tecnologie e catene di sicurezza differenti.
La distinzione conta. Un componente commerciale può essere economico e potente, ma va qualificato per radiazioni, vibrazioni, consumi e durata. L’open source evita riscritture, non sostituisce la certificazione. La vera innovazione sta nell’architettura: separare le funzioni critiche, isolare gli errori, progettare fallback e aggiornamenti, documentare ciò che accade quando la normalità finisce.
Il codice come vantaggio competitivo per la space economy
Qui il software spaziale smette di essere soltanto una storia tecnica e diventa una questione industriale. Una costellazione deve coordinare migliaia di decisioni; un satellite di osservazione deve selezionare dati e pianificare acquisizioni; un veicolo lunare deve operare lontano dal controllo diretto. Il software decide una parte crescente delle prestazioni, dei costi di manutenzione e della vita economica degli asset.
Per l’Europa questa partita attraversa sia le grandi piattaforme sia le PMI della filiera: computer di bordo, flight software, sistemi di guida e navigazione, cybersecurity, simulazione, validazione, ground segment. Gli standard europei ECSS rendono verificabili soluzioni di fornitori diversi. Servono prove, processi ripetibili, controllo delle versioni e proprietà intellettuale difendibile. È qui che un’impresa di software può diventare un fornitore strategico, e non un semplice subappaltatore di ore.
AI, sicurezza e futuro dei sistemi spaziali autonomi
La prossima frontiera è decidere di più a bordo: riconoscere anomalie, aggirare ostacoli, scegliere finestre operative, adattare attività scientifiche. Ma come si verifica un algoritmo davanti a eventi mai osservati? E come si evita che un attacco informatico o un aggiornamento sbagliato colpiscano un’intera costellazione? La risposta non può essere «fidarsi dell’intelligenza artificiale».
NASA insiste su software assurance, sicurezza, verifica e validazione indipendente. La lezione vale anche per gli investitori: nel settore spaziale l’elemento più raro non è sempre il codice, ma l’evidenza che quel codice possa volare. Test, tracciabilità e qualificazione rappresentano costi; insieme, però, formano barriere all’ingresso. Il vantaggio di un software affidabile si accumula missione dopo missione.
Da 1202 a domani: controllare l’imprevisto
Si torna così al display di Apollo 11. Non fu la potenza a salvare la missione, ma la capacità di escludere il superfluo. Voyager insegna la longevità, lo Shuttle la diversità delle difese, Pathfinder la disciplina delle priorità, i rover l’autonomia, Ingenuity il valore di software riusabile. La traiettoria è una: più intelligenza a bordo, senza perdere il controllo umano.
Il futuro non apparterrà necessariamente al veicolo con il computer più veloce. Apparterrà a quello che continuerà a fare la cosa giusta quando il segnale da Terra non sarà ancora arrivato, un sensore mentirà o un pezzo di memoria smetterà di funzionare. L’ultima frontiera del software spaziale, in fondo, non è imparare a pensare come noi. È imparare a non lasciarci soli nel momento in cui l’errore costerebbe tutto.
Fonti e approfondimenti
Infografica di partenza: New Space Economy, «The Evolution of Spacecraft Software». Le cifre sulle righe di codice sono indicative e non direttamente confrontabili fra missioni. Seguono documenti istituzionali e tecnici per approfondire.
01 Apollo Guidance Computer, memoria e allarmi 1201/1202 — NASA, Apollo 11 Lunar Surface Journal.
https://www.nasa.gov/wp-content/uploads/static/history/alsj/a11/a11.1201-pa.html
02 Margaret Hamilton e il software delle missioni Apollo — NASA.
https://nasa.gov/wp-content/uploads/static/history/alsj/a11/a11Hamilton.html
03 Architettura dei computer di bordo Voyager — NASA Science, FAQ.
https://science.nasa.gov/mission/voyager/frequently-asked-questions/
04 Riparazione del Flight Data System di Voyager 1 — NASA Science, 22 aprile 2024.
https://science.nasa.gov/blogs/voyager/2024/04/22/nasas-voyager-1-resumes-sending-engineering-updates-to-earth/
05 Avionica e ridondanza dei computer Shuttle — NASA, Computers in Spaceflight.
https://www.nasa.gov/wp-content/uploads/static/history/computers/Ch4-4.html
06 Mars Pathfinder e priority inversion — ricostruzione tecnica del team NASA/JPL.
https://postmortem.io/incidents/nasa–1997-07-04–mars-pathfinder-priority-inversion/
07 Curiosity e sistema operativo VxWorks — Wind River / NASA JPL.
https://www.windriver.com/success-stories/nasa-jpl
08 Guida autonoma di Perseverance — NASA.
https://www.nasa.gov/solar-system/nasas-self-driving-perseverance-mars-rover-takes-the-wheel/
09 Mars Global Localization — NASA, 18 febbraio 2026.
https://www.nasa.gov/missions/mars-2020-perseverance/perseverance-rover/nasas-perseverance-now-autonomously-pinpoints-its-location-on-mars/
10 Framework F Prime e Ingenuity — NASA JPL.
https://www.nasa.gov/missions/meet-the-open-source-software-powering-nasas-ingenuity-mars-helicopter/
11 Bilancio dei 72 voli di Ingenuity — NASA, 25 gennaio 2024.
https://www.nasa.gov/news-release/after-three-years-on-mars-nasas-ingenuity-helicopter-mission-ends/
12 Software Assurance and Software Safety Standard — NASA.
https://sma.nasa.gov/sma-disciplines/software-assurance-and-software-safety
13 Standard del software per progetti spaziali — ESA / ECSS.
https://www.esa.int/TEC/Software_engineering_and_standardisation/TECMKDUXBQE_0.html
Partecipa alla community