Quella che segue è la trascrizione del tredicesimo episodio di Houston, un podcast di Media Inaf che parla di spazio, atterraggi falliti, innovazioni disperate e soluzioni geniali. Ideato, realizzato e condotto da Valentina Guglielmo, quest’episodio – pubblicato per la prima volta il primo febbraio 2025 – parla delle missioni Cluster ed Exosat e ha come ospite il fisico Paolo Ferri. Potete ascoltarlo su Apple Podcasts, su Spotify e su YouTube. Oppure direttamente da qui.
Crediti per le immagini di Cluster e del centro di controllo di Exosat: Esa
Paolo Ferri
E questa è un’operazione che oggigiorno nessuno neanche si sognerebbe di fare, perché siamo tutti ad altissimo livello. Parli con un moderno programmatore di software e gli dici bit e byte, lui ti ride in faccia, ma non sa neanche cosa sono. Invece, a quei tempi, si lavorava ancora molto con queste cose quando si parlava con i satelliti, soprattutto con quelli antichi.
[inizio musica]
Valentina Guglielmo
Bit e byte, zero e uno, sequenze, caratteri, memoria. Quando parliamo di queste unità oggi, più che altro in termini di gigabyte e terabyte, di solito le pensiamo come unità di memoria. Contenitori di informazioni più o meno capienti. Quanti video, foto, immagini riuscirò a guardare, scaricare o postare con un certo numero di giga? Un ragionamento corretto, in linea di principio, e forse anche l’unico sensato considerando l’uso che facciamo di queste informazioni. Ma non è così nel mondo dell’informatica, e non è così nel mondo dell’ingegneria spaziale. Anche qui strumenti e sistemi elettronici a bordo dei satelliti si sono evoluti nel tempo, ma quando si tratta di risolvere problemi – conoscere le radici di queste architetture informatiche può rivelarsi essenziale. In questa puntata, assieme a Paolo Ferri, ci addentreremo un po’ nel mondo dei software di bordo delle missioni spaziali, attraverso due esperienze accadute fra gli anni ’80 e ’90 che sono sopravvissute proprio grazie alla conoscenza, nel dettaglio, del linguaggio dell’informatica.
Io sono Valentina Guglielmo e questo è un podcast di Media Inaf che parla di spazio, atterraggi falliti, innovazioni disperate e soluzioni geniali. Si chiama Houston.
[fine musica]
Valentina Guglielmo
Bit e byte, dicevamo. Sono le unità alla base del trasporto dell’informazione e dei comandi informatici, sono l’alfabeto della programmazione. Per quanto oggi qualunque linguaggio di programmazione abbia parole e frasi già pronte per scrivere nuove istruzioni o nuovi comandi, conoscere le lettere è fondamentale quando queste parole, per qualche ragione, riportano errori ortografici.
Pensiamo al telefono senza fili. Ci avrete certamente giocato da bambini. Si parte da un capo del tavolo sussurrando una parola o una frase all’orecchio del vicino, ad esempio “Francesca è buona come il pane” e si continua, orecchio dopo orecchio, fino a tornare al punto di partenza. Il risultato potrebbe essere una cosa come “una pesca è buona come il cane”. Completamente diversa, storpiata e pure senza senso. Ecco, se vi dicessero solo la fine e vi chiedessero di indovinare qual era la frase originale, probabilmente vi mettereste a cercare assonanze, a sostituire lettere, e in qualche modo cerchereste di smontare la frase pezzo per pezzo. Ecco, tornando alla programmazione, quella consonante o vocale che cambia è come un bit che salta in un’istruzione informatica. E come voi che cercate di trovare dove si è inserito l’errore, un programmatore cerca di scavare a fondo smontando, pezzo per pezzo, il codice che si trova davanti.
Una cosa semplice – ammesso che si conosca come procedere – oggi che possiamo farlo stando seduti di fronte a uno schermo in cui qualunque cosa è modificabile e cancellabile con due clic. Non era così invece negli anni Settanta, quando programmare significava costruire schede fisiche e saldare circuiti elettrici. Un po’ la differenza fra scrivere con martello e scalpello nelle tavole di pietra, o prendere un foglio e scrivere con matita e gomma.
In questa puntata parleremo di due missioni meno recenti, sopravvissute a due guasti proprio grazie alla conoscenza profonda dei software e dell’elettronica di bordo. La prima si chiama Exosat, è un telescopio a raggi X come Xmm-Newton ed è stata la testimone di un momento di transizione importante: il passaggio da circuiti elettrici saldati a bordo del satellite, a unità riprogrammabili da terra. Vedremo a breve di che si tratta. La seconda si chiama Cluster, è una missione che invece di osservare il cielo osservava la terra, e il suo guasto riguarda uno strumento di bordo di nome Wec.
Ma prima di scoprire come si sono salvate, vi voglio raccontare un po’ come è avvenuta questa evoluzione informatica nelle missioni spaziali. Forse vi sembrerà di ascoltare un podcast di informatica, più che di spazio, ma tantissimi dei problemi che succedono a bordo di un satellite o di una sonda hanno a che fare con l’informatica. E a volte gli ingegneri spaziali per risolverli devono diventare un po’ anche degli hacker. Se però proprio l’informatica non vi va giù, non temete, dalla prossima puntata torneremo a parlare di schianti, satelliti che non si trovano più e missioni salvate in corner.
[musica]
Nei racconti di Ferri sentiremo termini come “circuiti fissi” e “logica di bordo” fissata nella memoria, oppure parleremo software riprogrammabili. Quando si lancia un satellite, si carica a bordo anche una serie di istruzioni, che gli dicono cosa fare in ogni situazione e anche in caso di malfunzionamento. E come sono scritte queste istruzioni al suo interno? Fino agli anni Settanta, il confine fra elettronica e informatica era molto più confuso e il software era più che altro hardware. Il manuale di istruzioni di un satellite era un po’ come la tavola di pietra che dicevamo prima. E se oggigiorno per decidere quale comando eseguire in una determinata situazione la strada è scritta a colpi di tastiera con righe di codice, una volta era definita a colpi di saldature e interruttori in un circuito elettrico. Con la differenza che se questi circuiti si trovano a milioni di chilometri di distanza è impossibile aggiustare o cambiare qualsiasi cosa. Fino agli anni Settanta, quindi, i satelliti avevano, il manuale di istruzioni, che sentiremo chiamare logica di bordo, integrato in un circuito elettrico. Che significa che c’erano proprio degli interruttori che si aprivano o si chiudevano nel circuito, determinando la “strada” da far prendere alla corrente. In questo modo, il circuito gestiva le unità da far funzionare, le modalità di utilizzo o i messaggi d’errore.
[fine]
Paolo Ferri
Negli anni Settanta, questi partivano o con i circuiti integrati, o al massimo avevano un computer con una Prom, quindi con una memoria fissa. Si usava il termine “burn a prom”, e voleva dire che quando avevi il software definitivo lo mandavi a una ditta, e questa ditta con delle macchine a ultravioletti ecc, fissava la logica in queste Prom. E poi le prom – programmable read only memories come si chiamavano – eseguivano il programma e basta, tu non potevi cambiare nulla. Poi c’è stata l’evoluzione successiva, quella di mettergli le Ram – random access memories – che erano appunto riprogrammabili. Di solito erano memorie vuote quando accendevi il computer, il computer caricava dalla Prom il software nella Ram, a quel punto finché era alimentato dalla corrente girava il software e tu potevi modificarlo con dei comandi. Poi se si spegneva, perdevi tutto…
Valentina Guglielmo
…E ripartiva dalla prom
Paolo Ferri
Sì, doveva ripartire dalla prom. Questo è stato il passo successivo. Dopo, ed è la situazione attuale, c’è ancora la Prom se vuoi, ma la Prom è riprogrammabile. La differenza fra la Prom e la Ram è che adesso la prom può essere riprogrammata da terra e non perde il software quando si spegne.
Valentina Guglielmo
Quindi prima quando la prom passava il software alla ram se c’era un safe mode si ripartiva da zero?
Paolo Ferri
Praticamente sì. Con Cluster succedeva esattamente questo. Se il satellite perdeva completamente il power, come per esempio succede ancora oggi quando vanno in eclisse, questa memoria si svuotava. Quindi lui ripartiva dalla Prom e noi poi a mano dovevamo mandargli tutti i comandi per far ricaricare tutte le modifiche al software che si sono accumulate in vent’anni e poi anche quei comandi particolari. E questo succede ancora oggi con cluster: tutte le volte che va in eclissi si spegne, perde tutto tranne il software della Prom. E il software della Prom è quello arcaico degli anni ’90.
Valentina Guglielmo
Ricapitolando, quindi, ci sono stati vari passaggi. Prima, i circuiti integrati, scolpiti nella pietra. Come un telefono nel quale non potete modificare o installare niente, e in cui se non funziona qualcosa dovete cambiare telefono. Poi, il software con un computer che lo eseguiva, utilizzando una memoria fissa che non poteva essere modificata. Cioè un telefono in cui, ogni volta che lo accendete, dovete installare tutte le app, la rubrica e tutto ciò che avete aggiunto nel tempo. Infine, e questa è la situazione attuale, il massimo della flessibilità con memorie che non perdono il software quando si spengono e sono completamente riprogrammabili. Si chiamano eeprom, electrically erasable programmable read-only memory, e funzionano un po’ come il disco rigido del computer. Continuando con l’analogia del telefono, potete scaricare app, modificare impostazioni e fare aggiornamenti e nulla verrà perso quando spegnete il telefono.
In una telefonata di qualche giorno fa, fra auguri di buon anno e nuovi libri in uscita, Ferri mi ha raccontato che la transizione fra circuiti fissi e software riprogrammabili è avvenuta fra gli anni ’70 e ’80 del secolo scorso.
Paolo Ferri
Allora, negli anni ‘70 per esempio Voyager era riprogrammabile, Pioneer no. Pioneer l’hanno lanciato all’inizio degli anni ‘70, tipo 73, 1972-1973 credo. Voyager è partito nel ‘77, lì c’è stata in America la transizione. In Europa è arrivata dopo, perché appunto Exosat, lanciato nell’83 ma progettato alla fine degli anni ‘70 è stato il primo che ha messo un computer riprogrammabile. Però non era il computer principale che gestiva la missione, era solo questo affarino aggiuntivo che serviva per comprimere i dati scientifici. Quindi se vuoi è stato un passaggio ulteriormente intermedio. Il satellite in sé non so se avesse solo circuiti integrati o un computer principale, francamente non me lo ricordo, però sicuramente non era possibile modificare niente della sua logica, quella che gestiva la piattaforma, il satellite.
Valentina Guglielmo
Fine della digressione informatica e parliamo finalmente di missioni spaziali.
Cominciamo con Exosat, uno dei primi satelliti dell’Agenzia spaziale europea. Il nome sta per European X-ray Observatory Satellite – era cioè un satellite che osservava nei raggi X, come XMM Newton. Fu lanciato il 26 maggio 1983 ed è stato il primo satellite europeo a portare un computer riprogrammabile a bordo. La funzione di questo computer però era solamente comprimere e inviare i dati scientifici a terra, mentre le funzioni di base del satellite erano ancora fissate nei circuiti elettrici. Senza questo computer però Exosat non sarebbe sopravvissuto.
Paolo Ferri
Bene, Exosat era un satellite degli anni 80, quindi lanciato subito già al lancio aveva avuto problemi, si guastavano tutti sti satelliti a quei tempi. Quando sono arrivato io era in volo da un anno e praticamente aveva già perso tutta la ridondanza dei sottosistemi, aveva perso metà del payload. Si era guastato già tutto…metà, metà. Infatti probabilmente era normale che sopravvivesse due anni. Poi al fine ha resistito tre anni, poverino, però ne succede di tutti i colori.
Valentina Guglielmo
Un giorno, circa due anni dopo il lancio, nel 1985, il circuito in carica di controllare la salute dei giroscopi di Exosat ha cominciato a ritenere che questi non funzionassero bene, e in risposta ha cominciato a far scattare continui safe mode. I giroscopi, in verità, funzionavano benissimo, ma per qualche motivo quella parte di circuito si era guastato.
Uscire da un safe mode, però, significava perdere almeno un paio di giorni per recuperare il satellite, rimetterlo in assetto e ricominciare con le operazioni. Perdendo fra l’altro un sacco di propellente, e interrompendo il lavoro vero del satellite, cioè le osservazioni astronomiche a raggi X. Era una situazione insostenibile, sia per gli ingegneri che perdevano un sacco di tempo, sia per gli scienziati che avevano solo tre anni per usare questo strumento, e vedevano saltare i loro piani a metà.
Paolo Ferri
Dopo due o tre volte si è detto non possiamo andare avanti così con i safe mode che partono a caso. Sapevamo che era un problema dell’elettronica, non era un problema dei giroscopi, ma questa elettronica semplicemente non funzionava, non si poteva modificarla. Però non volevamo neanche disabilitarla perché se poi succedeva un problema con il giroscopio avremmo perso il satellite. A quel punto non so a chi venne in mente, perché appunto erano discussioni che avvenivano nel team delle operazioni, noi eravamo un po’ lì ad aspettare che risolvesse il problema, ci dicono “ma voi non avete mica il computer per fare la compressione dei dati? Perché non usiamo quello?”. In effetti noi nel team avevamo una ragazza che era di una ditta che aveva sviluppato il software di bordo e che era impiegata permanentemente nel nostro team per sviluppare algoritmi nel software di bordo di questo computer dei dati, e lei lavorava su queste cose: ottimizzava la compressione, sviluppava codici se a qualcuno veniva qualche idea, eccetera.
Valentina Guglielmo
L’idea che venne in mente al team delle operazioni era: disabilitare temporaneamente i circuiti elettronici incaricati di controllare i giroscopi, e scrivere un software da implementare nel computer di bordo riprogrammabile per controllare davvero il funzionamento dei giroscopi. Si trattava comunque di un controllo passivo, perché il computer non avrebbe in alcun modo potuto dare indicazioni operative al satellite. Eravamo ancora lontani da una funzionalità di questo tipo, all’inizio degli anni ’80. Ma nel caso in cui il computer avesse riscontrato qualche anomalia, avrebbe potuto comunicarla al team di terra, che a quel punto avrebbe riabilitato i circuiti elettrici danneggiati causando volontariamente un safe mode.
Paolo Ferri
Era praticamente aggirare, sostituire il lavoro dell’elettronica e questo era per noi completamente nuovo ma in realtà è stato precursore di quello che poi abbiamo fatto in tantissimi altri casi. Oggi tutti i satelliti sono riprogrammabili ovviamente, anzi tante unità sono riprogrammabili ed è una cosa che si fa spesso. Spesso non si va nemmeno a correggere una logica perché magari quella logica è troppo profondamente legata al resto del software e si ha paura di fare dei guasti. Allora la metti da parte, scrivi un programmino che la sostituisce e che sta a un livello superiore e quando lui ha preso la decisione giusta allora riaccende quella logica ed esegue. Quindi un concetto che poi è stato usato tantissimo nella mia carriera. Quella fu la prima volta. Quindi questa ragazza si mise a implementare questo software, tra l’altro stiamo parlando degli anni ‘80, quindi il software era tutto scritto in assembler, erano cose veramente molto molto primitive però anche molto flessibili, cioè con quattro byte facevi dei miracoli. Oggi un programmatore se non ha una memoria di qualche terabyte non scrive niente. Invece allora si lavorava veramente con un paio di kilobyte e appunto lei sviluppò questo programma, non avevamo neanche molte capacità di testare prima quindi si presero anche dei rischi diciamo a testarlo in volo, però praticamente risolse completamente il problema. Il problema era il safe mode e solo questo prolungò la vita sicuramente di un anno, che sulla vita totale di tre anni non è poco.
Valentina Guglielmo
Spesso, dice Ferri, nemmeno ci si mette a correggere il problema software, quando emerge, ma si cerca il modo di aggirarlo. Alcune volte, però, capita che l’unico modo per risolvere un problema sia scavare veramente a fondo nel software che fa eseguire operazioni e comandi al satellite. E l’unico modo per farlo è conoscere e capire nel dettaglio l’architettura e il linguaggio con cui sono scritti i codici. Ricordate i bit e i byte dell’inizio? Ecco, proprio quelli hanno salvato lo strumento Wec a bordo di uno dei satelliti Cluster.
[stacco musicale]
I satelliti Cluster sono quattro navicelle identiche disposte in formazione per studiare la magnetosfera terrestre.
[inizio musica]
La magnetosfera è una regione di spazio che circonda la terra, in cui il campo magnetico del nostro pianeta funge da scudo alle particelle cariche provenienti dal vento solare confinandole nelle cosiddette Fasce di Van Allen. L’interazione fra la magnetosfera e le particelle cariche del vento solare dà origine alle aurore. E come dicevamo nella scorsa puntata di Houston in merito agli studi della sonda Ulysses, le particelle cariche che compongono il vento solare, per lo più elettroni e protoni, sono anche responsabili di tempeste geomagnetiche che disturbano i satelliti, le comunicazioni, e gli astronauti in orbita.
[fine musica]
Valentina Guglielmo
Per dare un’idea di cosa succeda quando le particelle del vento solare incontrano la magnetosfera della terra, l’agenzia spaziale europea ha realizzato due sonificazioni delle onde magnetiche misurate da Cluster in due condizioni “meteo” molto diverse. Sentiamo la prima
[prima sonificazione delle onde magnetiche misurate da Cluster]
Sonificare un segnale significa prendere lo spartito generato dal susseguirsi delle frequenze di un segnale e riportarlo a frequenze udibili dal nostro orecchio. Ora, sono d’accordo con voi che quello che abbiamo sentito è lontano dall’essere qualcosa di orecchiabile o piacevole, ma sentite la differenza con il suono delle onde magnetiche durante una tempesta solare.
[sonificazione delle onde magnetiche misurate da Cluster durante una tempesta solare]
Ecco, in questa melodia – se così possiamo chiamarla – le onde magnetiche raddoppiano la loro frequenza e in generale creano degli spartiti molto più complicati, per effetto della turbolenza magnetica generata dalla tempesta solare. Tradotto in suono, questo segnale diventa circa un’ottava più alto del precedente ed è molto più variabile.
Ma torniamo a noi. I quattro satelliti della missione Cluster – che si chiamano Rumba, Salsa, Samba e Tango – sono stati lanciati a coppie il 16 giugno e il 9 agosto 2000 dal cosmodromo russo di Bajkonur, a bordo di un razzo Sojuz. Da allora, e fino allo scorso anno, hanno orbitato a 190 mila chilometri dalla superficie terrestre formando varie figure geometriche. Il 9 settembre 2024, il secondo dei quattro, Salsa, è stato fatto rientrare in maniera controllata nell’atmosfera terrestre, concludendo così più di 24 anni di carriera.
Eseguire rientri controllati come quelli dei satelliti Cluster richiama attenzione, come abbiamo sentito in questo video dell’Esa, perché riguarda un problema molto attuale. Quello dell’accumularsi di detriti spaziali in orbita. La cosiddetta spazzatura spaziale, di cui ormai alcune orbite sono invase.
Ma non è per il rientro di Cluster che ho deciso di parlare di questa missione in questa puntata di Houston. Anche perché lì è andato tutto bene.
Il problema di cui vi voglio parlare, lo accennavo prima, riguarda uno degli strumenti di bordo. All’interno di ciascuno dei quattro satelliti, cinque degli undici strumenti erano infatti controllati da un unico modulo, una sorta di piattaforma elettronica chiamata Wec. Funzionava così: da terra venivano trasmessi i comandi a Wec che poi, autonomamente, gestiva i cinque strumenti di cui era responsabile dando loro corrente in maniera alternata, e curandosi quindi di non accenderne troppi contemporaneamente.
Un giorno d’inizio marzo 2011, per una ragione che non fu mai chiarita, è successo che più strumenti siano rimasti accesi contemporaneamente prima dello spegnimento di Wec. Quando il team di cluster a terra ha provato a riaccenderlo, la volta successiva, tutti i circuiti chiusi degli strumenti richiedevano corrente contemporaneamente creando un picco, tanto che il limitatore di corrente associato al tasto di accensione di Wec, registrando questo flusso eccessivo si riapriva, spegnendo nuovamente lo strumento. Il tutto nel giro di qualche millisecondo. Scattava una sorta di salvavita, in pratica. E la cosa creava un circolo vizioso: per risolvere il problema, infatti, bisognava prima accendere Wec, spegnere gli strumenti, e poi ricominciare le normali attività richiedendo un flusso di corrente adeguato.
Il problema, anche se riguardava solo uno dei quattro satelliti, condizionava l’attività scientifica di tutti e quattro. I loro sensori infatti dovevano lavorare insieme per effettuare osservazioni accurate: perdere anche solo uno di essi avrebbe potuto compromettere seriamente le indagini scientifiche.
Quanto al problema deIlo strumento, nel 1995, prima del lancio, il team di Cluster aveva simulato cosa sarebbe potuto accadere se tre dei cinque interruttori fossero rimasti accesi in contemporanea, ma nessuno aveva mai pensato a come recuperare lo strumento se tutti e cinque fossero stati bloccati. Banalmente, perché nessuno pensava che si potesse verificare una situazione del genere.
Paolo Ferri
Quindi siccome tutti quei così erano chiusi noi avremmo dovuto prima accenderlo e poi aprirli. Quindi prima chiudere il pulsante a monte e poi aprire quelli a valle. Immaginati di avere 10 lampadine ciascuna col suo pulsantino per accenderla. Per caso sono stati tutti schiacciati in accensione, ma la scatola che hai a monte per accenderle non può portare la corrente di dieci lampadine. Può portare fino a otto. Ogni volta che accendi questa, lei scatta perché scatta, se vuoi, il salvavita, perché la corrente è troppo alta. Ma noi per poter aprire quei pulsanti e quindi riuscire ad abbassare il consumo di corrente, dovevamo accenderla, quindi era un circolo vizioso. Non mi ricordo com’è successo, è stata una cosa interna che è successa per sbaglio all’interno dello strumento. Non è stato neanche un errore operativo. Tutto d’un tratto ci siamo trovati in quella situazione, che era irresolubile.
Valentina Guglielmo
Una situazione da cui non si riusciva a uscire, se non inventandosi un qualche trucchetto.
I tentativi di recupero andarono avanti circa due mesi, fino al 1 giugno, quando, alle 08:30 e al secondo tentativo, il “comando taroccato” – come l’ha chiamato Ferri – ideato per far ripartire lo strumento ha funzionato. Vediamo di che si tratta.
L’idea venne a un ingegnere che lavorava alle operazioni di Cluster, Ignacio Clerigo. Clerigo pensò di usare la linea di corrente ridondante di Wec per distribuire il flusso di corrente richiesto dalla piattaforma al momento dell’accensione, dividendola su due linee in modo da evitare il picco che faceva saltare l’interruttore. Una soluzione che poteva funzionare, almeno in principio, se non fosse per un piccolo dettaglio: il tempo. Per eludere il limitatore di corrente, infatti, le due linee si sarebbero dovute accendere quasi contemporaneamente, prima che il sistema stesso si accorgesse del trucco. Una questione di millisecondi. Sentiamo Ferri.
Paolo Ferri
Benissimo, noi mandiamo i comandi a bordo del satellite per chiudere entrambi gli interruttori in parallelo, come mettere due dita insieme e schiacciare entrambi gli interruttori, ma la cosa non funziona. L’interruttore si riapre di nuovo. Perché non funziona? Perché, purtroppo, quando mandi due comandi a bordo del satellite, non è che vengano eseguiti esattamente allo stesso istante. Vengono incanalati lungo la linea di comunicazione verso l’unità che poi manderà l’impulso elettrico per chiudere l’interruttore, uno dietro l’altro. E quindi c’era una separazione temporale che probabilmente era dell’ordine delle decine di microsecondi, che però non era sufficiente a intervenire col secondo comando prima che il picco di corrente generato dal primo comando andasse sopra la soglia. A questo punto non avevamo più mezzi normali per intervenire, però non avevamo considerato l’ingegnosità di Ignacio Clerigo, il quale si mise a studiare la struttura della nostra istruzione per mandare il comando al satellite, proprio la struttura dei bit e byte che costruivamo per mandare questi comandi, che nel caso di Cluster era molto semplice. In questo senso, come dicevo all’inizio, forse la semplicità di questa struttura, o meglio l’antiquità di questa struttura – perché veramente era una cosa arcaica – ci ha aiutato in questo caso. Se fosse stata una struttura più moderna, pacchetti più di alto livello, non saremmo riusciti a risolverlo così. Magari sarebbe stato un satellite meglio riprogrammabile, ma chi lo sa.
Comunque, Ignacio è andato a studiarsi questa antica struttura, questi comandi a 96 bit, che tra l’altro io conoscevo molto bene perché erano quelli dei primi anni della mia carriera, Eureca funzionava così, Exosat funzionava così. Cluster, nonostante volasse in questo millennio, aveva ancora questa struttura antiquata.
Valentina Guglielmo
Lo stratagemma pensato da Ignacio era, invece di mandare due comandi separati da 96 bit, costruire ad hoc un comando unico in cui si davano le istruzioni contenute in entrambi i comandi di accensione. Una procedura vietata dalla progettazione della sonda, ma che secondo lui avrebbe funzionato. Ignacio infatti aveva studiato nel dettaglio come agivano il decodificatore e l’unità di distribuzione dei comandi sui singoli bit dei 96 che costituivano un singolo comando.
Paolo Ferri
Insomma lui si è inventato una sequenza di bit da inserire in questo messaggio standard da 96 che era completamente fuori dalla struttura che i comandi di Cluster dovevano eseguire, però secondo lui, seguendo poi cosa sarebbe successo a questi bit, avrebbe avvicinato in ordine di tempo le due istruzioni. E questa è un’operazione che appunto oggigiorno nessuno neanche si sognerebbe di fare, perché siamo tutti ad altissimo livello. Parli con un programmatore moderno di software, gli dici bit e byte, lui ti ride in faccia, non sa neanche cosa sono. Invece, a quei tempi, si lavorava ancora molto con queste cose quando si parlava con i satelliti, soprattutto con quelli antichi.
Valentina Guglielmo
Ricapitolando, quindi, mandando separatamente quei due comandi di accensione come da manuale, c’era una certa distanza di tempo fra le due operazioni, che faceva scattare il limitatore di corrente; condensandoli invece in un unico messaggio – un comando taroccato appunto – si riusciva ad avvicinare le esecuzioni ed evitare il picco di corrente che faceva scattare il limitatore.
Paolo Ferri
Ci sono state grandi discussioni con l’industria, che sosteneva che questo era un modo di comandare che non aveva nessun senso e che il satellite non avrebbe saputo neanche cosa farsene di un comando come questo, l’avrebbe scartato. Ma Ignacio, che era andato veramente nel dettaglio proprio del funzionamento di queste unità, era convinto che avrebbe funzionato. Nelle discussioni ci dicevano anche che si poteva creare un danno, ma alla fine nessuno poteva dimostrare che ci fosse davvero una controindicazione e quindi questo test l’abbiamo fatto. Abbiamo fatto prima un test, che adesso non ricordo bene in che termini, ma serviva per verificare che il satellite fosse in grado perlomeno di accettare di eseguire un comando di questo genere, senza andare a toccare quelle linee di comunicazione incriminate, quelle che poi causavano la corrente in eccesso. E poi dopo che questo test ha avuto successo, quindi dopo che abbiamo verificato che il satellite sapeva digerire ed eseguire il meccanismo inventato da Ignacio, abbiamo provato: abbiamo costruito apposta un comando che all’interno di un messaggio di 96 bit contenesse le istruzioni che chiudessero i due interruttori in parallelo, l’abbiamo mandato e magicamente lo strumento si è acceso. Si è acceso distribuendo appunto la corrente sulle due linee, mantenendo il picco era più basso, con la corrente che è rimasta sotto la soglia, e gli interruttori non si sono aperti.
Valentina Guglielmo
La soluzione per così dire non canonica inventata da Ignacio è stata chiamata dalla stessa agenzia spaziale europea, in un comunicato stampa pubblicato all’epoca per spiegare il problema, “dirty hack”. Un “trucco sporco”. Nello stesso comunicato però si leggono anche le parole di Manfred Warhaut, l’allora Direttore delle operazioni all’Esa. Cito testualmente “Quando tutto va come previsto, far volare una missione è un lavoro di routine, ma quando si verificano problemi inaspettati, e non c’è nulla che possa aiutare nei manuali, l’unica speranza è avere a disposizione un team esperto e di talento che riesca a risolvere il problema”.
Insomma, quando le soluzioni canoniche non funzionano, vanno benissimo anche i trucchetti sporchi. Ed è anche un po’ quello che dicevamo all’inizio, e che mi diceva Ferri a più riprese durante la nostra chiacchierata: nello spazio a volte è necessario saper scavare fino al dettaglio più piccolo, fino all’ultimo bit, per poter risolvere un problema. Bisogna essere un po’ più hacker e un po’ meno ingegneri. E se penso al modo in cui ho cominciato a programmare io stessa, da studente, dottoranda e poi ricercatrice, mi rendo conto di quanto sia diverso l’approccio alla programmazione richiesta oggi per scrivere e far funzionare un qualunque codice in python, ad esempio, uno dei linguaggi di programmazione più usati oggi.
Paolo Ferri
Ormai stiamo parlando di programmatori software che non programmeranno neanche più software, ma che dicono chat GPT di scriverlo. Quindi abbiamo sempre più delegato ad algoritmi la nostra conoscenza. Quando, su Rosetta, dovevo assumere un ingegnere per quello che chiamiamo onboard software maintenance, quindi, un ingegnere che fosse esperto del software di bordo, che sapesse come funzionava per poterlo modificare in volo –una responsabilità spesso si lascia all’industria, mentre noi per Rosetta essendo una missione così lunga la volevamo prendere in cassa – io volevo una persona che avesse queste capacità. E sto parlando del 2000, quindi 24 anni fa, un quarto di secolo fa. Ebbene, era difficilissimo trovare un softwarista un quarto di secolo fa che fosse in grado di gestire i bit e i byte, figuriamoci oggi. Alla fine l’ho trovato e questa persona molte volte ci ha tirato fuori da situazioni molto complesse grazie alla sua capacità di andare a scavare a quei livelli, e tante volte mi sono trovato io a dovere leggere l’esadecimale dei pacchetti che ci arrivavano per capire cosa stesse succedendo. Ricordo quando le nuove generazioni di ragazzi che avevo assunto per Rosetta – sto parlando anche lì proprio del cambio di millennio – che quando venivano assunti e venivano a lavorare mi vedevano in sala controllo che guardavo gli esadecimali. Avranno pensato “Ma dove sono capitato, son tornato all’età della pietra”, e invece poi hanno capito quanto fosse importante. Immagino che anche adesso, e alcuni esempi li abbiamo anche visti, il lavoro coi satelliti va ancora fino a quel dettaglio.
[inizio musica]
Valentina Guglielmo
Nonostante vari problemi abbiano messo a rischio la sopravvivenza dei quattro Cluster negli anni, tre di questi sono ancora in orbita attorno alla Terra dopo più di 24 anni. Ma quello che non abbiamo detto in questa puntata, è che i quattro satelliti che hanno volato non erano quelli originali, ma sono stati assemblati nel giro di quattro anni, dal 96 al 2000, dopo l’esplosione del razzo Ariane 5 che doveva mettere in orbita i primi quattro. Un evento tragico, che per fortuna non coinvolse alcuna vita umana, ma che segnò profondamente la carriera di alcuni esperti coinvolti. Fra tutti, Paolo Ferri, che ci racconterà come l’ha vissuta e quali conseguenze ha pagato nella prossima puntata. Io sono Valentina Guglielmo e vi aspetto nella prossima puntata di Houston, un podcast di Media Inaf che parla di spazio, atterraggi falliti, innovazioni disperate e soluzioni geniali.
[fine musica]
Ascolta Houston sul canale YouTube di MediaInaf Tv: