Costruire una missione

I primi tempi della preparazione di Rosetta furono molto intensi. Erik e io eravamo eccitatissimi. Avevamo passato gli ultimi anni, su Eureca prima e su Cluster poi, a cercare soluzioni ai nostri problemi e necessità operative usando sistemi creati da altri, dai nostri predecessori, senza che avessimo avuto la possibilità di influenzarli nelle fasi iniziali di progetto e di preparazione. Ma ora avevamo finalmente l’opportunità di cominciare da zero: la missione e il suo segmento di terra erano un foglio bianco su cui potevamo progettare tutto dall’inizio, in modo pulito e completo. Una missione completamente nuova, come nessuna mai era stata controllata dall’ESOC. Tutto da inventare, facendo tesoro delle nostre esperienze di volo precedenti.

I primi lavori concettuali

Cominciammo a scrivere documenti concettuali, per spiegare agli altri quello che avevamo in mente, ma anche e forse soprattutto per chiarirlo a noi stessi. Era un terreno nuovo, la nostra mente era piena di idee su cosa fosse veramente importante e su cosa si dovesse assolutamente evitare. Ma era difficile mettere nero su bianco da zero un progetto completo e un approccio altamente innovativo. Una delle nostre prime idee fu di definire un sistema di controllo di volo che fosse largamente derivato dal sistema usato dalla ditta che integrava la sonda Rosetta per controllarne i sistemi di bordo durante i test e verificarne la funzionalità. Poi cercammo di applicare a Rosetta il modello architetturale del software di gestione dati di bordo della nostra vecchia e cara Eureca. Conoscevamo bene il software di bordo di Eureca, e sapevamo che grazie alla sua flessibilità era stato possibile salvare la missione, qualche anno prima, quando varie parti del satellite si guastarono una dopo l’altra: modificando il software di bordo e usando la sua modularità eravamo riusciti ad adattare rapidamente durante il volo le sue funzioni ai continui cambiamenti del satellite, causati dai guasti dei suoi strumenti e di altre parti elettroniche e meccaniche. Rosetta aveva davanti un volo di almeno dieci anni, durante i quali era logico aspettarsi guasti di unità e funzioni a bordo che ovviamente non potevano essere riparate. Ciò che potevamo modificare da terra durante il volo era solo il software di bordo. Diventava perciò essenziale che il software fosse adattabile in modo semplice e strutturato, così come lo era stato per Eureca.

Dovevamo anche adattare il nostro modo di vedere le comunicazioni con la sonda e le interazioni con le funzioni autonome a bordo: Eureca volava attorno alla Terra a 500 chilometri di quota. Rosetta avrebbe raggiunto distanze di un miliardo di chilometri. I segnali radio viaggiano alla velocità della luce, 300.000 chilometri al secondo, ma anche a questa velocità inimmaginabile impiegano decine di minuti a percorrere le distanze come quelle che ci avrebbero separato da Rosetta durante il suo lungo viaggio nel sistema solare. Erik inventò per questo un sistema semplice di trasmissione di telecomandi che avrebbe garantito una ricezione sicura a bordo della sonda, indipendentemente dai tempi di risposta della sonda, che si sarebbero allungati con il crescere della distanza da Terra.

Jürgen allo stesso tempo cominciò a circondarsi dei pochi esperti all’ESOC che avevano lavorato sulle missioni Giotto o Ulysses, le uniche missioni ESA, fino ad allora, che avevano lasciato l’orbita terrestre. Non erano molti, ma uno di loro, Trevor Morley, era già a quel tempo considerato uno dei massimi esperti mondiali nel campo della determinazione della traiettoria di un veicolo spaziale, cioè la sofisticata arte di analizzare i segnali radio ricevuti da una sonda che vola nello spazio profondo e derivarne una stima accurata della sua posizione e velocità, in modo da poter poi ricavarne anche una previsione sufficientemente precisa e affidabile della sua traiettoria futura. Era una tecnica che per Rosetta sarebbe stata vitale, e Trevor era la persona adatta per portare e diffondere nel team della dinamica del volo il suo bagaglio di esperienza. Ma Jürgen sapeva benissimo che non avrebbe potuto progettare e implementare gli strumenti matematici e informatici necessari per far navigare Rosetta nel suo lungo volo nel sistema solare senza l’aiuto degli unici esperti di volo interplanetario allora esistenti: i colleghi della NASA che lavoravano al mitico Jet Propulsion Laboratory di Pasadena. Usando i suoi contatti dai tempi di Giotto e quelli ancora attivi per Ulysses, e con il supporto incondizionato di Manfred, Jürgen stabilì un accordo formale per lo scambio di conoscenze, dati di volo, e anche di soluzioni orbitali per tutta la durata del volo. Definì con la NASA anche interfacce tecniche per permetterci durante il volo di passare periodicamente le nostre misure del segnale radio di Rosetta alla NASA, in modo da permettere loro di rifare i nostri calcoli della traiettoria e verificare così indipendentemente la validità dei nostri. Questa idea fu fondamentale per la nostra missione, soprattutto per la fase di volo interplanetario, ma fu anche la base per una cooperazione a lungo termine che oggi, dopo il successo della navigazione di Rosetta attorno al nucleo della cometa, ha anche cambiato direzione, permettendoci di ripagare gli amici della NASA dell’aiuto ricevuto, aiutandoli a far navigare le loro sonde attorno ad asteroidi e comete.

I primi incontri con l’industria

Intanto il progetto della sonda cominciava a definirsi. Nei primi mesi del 1997 era stato firmato il contratto formale con la ditta che sarebbe stata responsabile di progettare e costruire Rosetta, la Dornier di Friedrichshafen, sul Lago di Costanza, la ditta tedesca di maggiore esperienza nel campo delle missioni scientifiche dell’ESA. Si era deciso inoltre, per la prima volta per una missione scientifica, data la sua importanza e complessità, di costituire un consorzio industriale formato da un capo-commessa, la Dornier appunto, e ben tre sotto-capi commessa, così da mettere insieme tutta l’esperienza rilevante allora presente in Europa. E così la Matra-Marconi Space di Tolosa fu selezionata, verso la fine del 1997, come responsabile di tutta l’avionica di bordo, cioè del complesso sistema di computer e strumenti che dovevano gestire il flusso di dati tra la sonda e la Terra, il sistema automatico di controllo di assetto, e tutta l’autonomia di bordo. Per il resto della piattaforma, cioè la sua struttura meccanica, il sistema di generazione e distribuzione della potenza elettrica, il controllo termico e il sistema di telecomunicazioni, fu scelta la British Aerospace di Bristol, in Inghilterra, che aveva già costruito Giotto. Infine, la responsabilità per integrare tutte le parti della sonda e collaudarle prima del lancio fu affidata all’Alenia di Torino.

I nostri rapporti con il consorzio industriale, e specialmente con la Dornier e la Matra, si intensificarono rapidamente nel corso di questo processo. Mentre conoscevamo quasi tutti i colleghi del team della Dornier, dato che avevamo lavorato con loro su Cluster negli anni precedenti, con quelli di Tolosa ci incontravamo per la prima volta. E fu l’incontro di due mondi diversi: il team e la ditta stessa avevano molta esperienza di satelliti di osservazione della Terra o di telecomunicazioni, e non avevano quasi mai lavorato con l’ESOC e su missioni scientifiche nel passato. Per complicare le cose, poco dopo l’assegnazione dei contratti per la costruzione di Rosetta, la Dornier e la Matra si fusero in una nuova unica ditta che chiamarono Astrium, e i nostri colleghi dell’industria si trovarono a dover affrontare in parallelo anche gli inevitabili problemi di adattamento generati da una tale fusione.

Le nostre riunioni con l’industria erano frequenti. Con i colleghi di Friedrichshafen discutevamo la definizione della missione, le sue fasi operative e le funzioni che la sonda doveva avere per poterle eseguire. Molte di queste riunioni furono difficili, con divergenze di opinioni a volte piuttosto forti su questioni fondamentali come l’ibernazione della sonda a grandi distanze dal Sole, le funzioni autonome e specialmente le reazioni automatiche della sonda a guasti eventuali delle sue funzioni. Invece a Tolosa cominciammo a discutere l’architettura del software di bordo che volevamo fosse progettato per Rosetta, sulla base della nostra esperienza con Eureca. Qui le discussioni, anche quelle di principio, furono ancora più complesse, dato che i colleghi della Matra volevano basarsi su architetture a loro familiari, di satelliti come SPOT, che avevano costruito nel passato recente. Solo che noi eravamo convinti che una missione interplanetaria, che vola a distanze da Terra di centinaia di milioni di chilometri, tali per cui il segnale radio, pur viaggiando alla velocità della luce, impiega decine di minuti a raggiungerla, debba avere funzioni autonome molto più sofisticate di un satellite che orbita attorno alla Terra a 800 chilometri di altezza.

Anche all’interno dell’ESA non mancavano le difficoltà iniziali, in particolare con il team responsabile del progetto all’ESTEC, il centro dell’ESA per la tecnologia spaziale situato a Noordwijk, sulla costa olandese del Mare del Nord. Molti di questo team provenivano dal progetto di Cluster, quindi ci conoscevamo bene e avevamo imparato a lavorare insieme negli anni della preparazione di quella missione. D’altra parte, come noi, non avevano mai lavorato nel campo delle missioni interplanetarie, e in più avevano poca esperienza di satelliti autonomi, cosa che invece era la nostra specialità. I rapporti creati negli anni della preparazione di Cluster, però, ci aiutarono a superare le divergenze di opinioni e formammo molto presto un team affiatato, anche se qualche incomprensione, nonostante tutto, rimase per anni.

La visita al Jet Propulsion Laboratory

Tutti ci rendemmo conto subito che la nostra esperienza su questo tipo di missioni, sia in ESA che nell’industria, era molto limitata e che dovevamo imparare il più possibile, e alla svelta, da chi aveva già fatto volare sonde nello spazio profondo, lontano dall’orbita terrestre. Seguendo l’esempio di Jürgen, che aveva stabilito con successo le connessioni giuste con i colleghi della NASA al JPL, Erik e io riuscimmo a convincere Manfred, e soprattutto il capo progetto di ESTEC, John Credland, che gestiva i fondi della missione, a mandarci in visita al JPL per incontrare gli esperti della NASA di volo interplanetario e imparare da loro il più possibile, e in fretta. Riuscimmo a organizzare una settimana di riunioni al JPL con vari team che stavano lavorando a missioni leggendarie come Voyager e Galileo o stavano preparando Mars Pathfinder. Così nel febbraio 1997 Erik e io, insieme a Jeff Noyes del team di progetto di ESTEC, partimmo per la California.

Il Jet Propulsion Laboratory era formalmente un laboratorio di ricerca del Caltech, California Technology Institute, l’università tecnologica di Pasadena, fondato negli anni Trenta del secolo scorso, che la NASA aveva incaricato fin dall’inizio dei voli spaziali di occuparsi non solo di propulsione, come il nome e la storia del JPL indicano, ma anche delle missioni robotiche, cioè senza esseri umani a bordo, che lasciavano l’orbita terrestre per esplorare il sistema solare.

La mia prima volta al JPL era stata alcuni anni prima, nel 1992, per una conferenza di operazioni spaziali che si teneva a Pasadena. Avevo avuto la possibilità di entrare come parte di un gruppo di normali visitatori. Ci avevano mostrato un paio di modelli di plastica delle sonde più famose e la sala controllo principale attraverso un vetro. Niente di speciale, né di impressionante. Poi vi ero tornato negli anni immediatamente successivi, durante la preparazione della missione Cluster, che era in cooperazione con la NASA. In queste visite eravamo entrati più a fondo nel mondo misterioso di quegli edifici imponenti, antisismici ma anche un po’ fatiscenti, sparsi sulle colline piuttosto impervie e spoglie dietro Pasadena. Era per me un luogo mitico, quasi sacro, anche se non potevo fare a meno di notare gli interni per noi piuttosto deprimenti, con i piani degli uffici organizzati in grandi spazi suddivisi da separatori di cartone alti un metro e mezzo in piccoli e tristi loculi che facevano da uffici – e che le cartoline e foto personali incollate con il nastro adesivo dagli occupanti in un tentativo di personalizzare il loro spazio privato non facevano che rendere ancora più infelici. Ci sembrava ancora più incredibile e impressionante che in quegli ambienti così poco accoglienti lavorassero i massimi esperti mondiali di esplorazione robotica del sistema solare.

La visita del febbraio 1997 però era un’occasione veramente speciale. Avrei incontrato e parlato con i protagonisti, quegli scienziati, ingegneri e tecnici che stavano operando o preparando il volo delle missioni più incredibili della storia del volo interplanetario. Galileo, la sfortunata missione verso Giove, che appena lanciata nel 1989 non riuscì ad aprire la grande antenna per le comunicazioni con la Terra. L’avevano progettata pieghevole, i tecnici della NASA, apribile come un ombrello una volta che la sonda si fosse separata dal lanciatore. E invece l’ombrello non si aprì mai, nonostante i vari tentativi di scaldarlo e agitarlo per sbloccare le parti meccaniche incastrate. La missione proseguì, con le comunicazioni possibili solo attraverso le antenne a basso guadagno, quelle che le sonde interplanetarie hanno per i casi di emergenza, quando qualche problema impedisce il puntamento automatico dell’antenna principale verso la Terra. Solo che con queste antenne il segnale radio è debolissimo, sufficiente per comandare la sonda, ma praticamente inutilizzabile per trasmettere i dati scientifici di telemetria. E qui la tipica ingegnosità degli operatori spaziali, che sono abituati a lavorare con macchine che non si possono riparare, aveva fatto miracoli: modificarono il software di bordo durante il viaggio verso Giove per comprimere il più possibile il flusso di bit che trasportava via radio i dati scientifici.

Anche sulla Terra si adottarono misure speciali, come quella di mettere più antenne in puntamento contemporaneo, sommando così il debole segnale radio ricevuto da ciascuna, che poi veniva decodificato a parte, e ottenendo una maggiore efficienza di ricezione. Era come avere una superficie di antenna grande il doppio. La NASA disponeva di tre antenne giganti del diametro di 70 metri, piazzate in tre punti diversi del globo, nei complessi della Deep Space Network in California, Australia e Spagna. Ovviamente furono le antenne da 70 metri che sostennero tutta la missione Galileo, che alla fine fu un successo – nonostante il problema con l’antenna di bordo – anche grazie alla sua longevità. Ricordo che quando incontrammo il team di Galileo ci impressionò la sua dimensione: era passato di recente da 350 persone a 50, per seguire la fase finale della missione. Per noi dell’ESOC anche un team di 50 persone era un sogno, e cominciavamo a domandarci se non avessimo sbagliato i conti a entrare nel mondo complesso e inesplorato delle operazioni interplanetarie. Parlammo anche con il team di Deep Space 1. La missione era ancora in preparazione, e potevamo discutere delle nuove tecniche usate per le comunicazioni digitali, dell’automazione a bordo e della telemetria a pacchetti e il suo uso a grandi distanze.

Ma il momento più emozionante fu quando ci fecero parlare con il team di Voyager. Le due sonde Voyager sono ancora oggi una leggenda, e sicuramente la missione più famosa di tutta la storia dell’esplorazione spaziale robotica. Lanciate alla fine degli anni Settanta per sorvolare, per la prima volta, Giove e Saturno, sfruttando una posizione favorevole dei pianeti che si verifica ogni qualche secolo, avevano avuto un successo tale che le loro missioni erano state prolungate, e avevano compiuto sorvoli anche di Urano e Nettuno, completando (o quasi, dato che allora Plutone era ancora considerato un pianeta) la serie dei pianeti del sistema solare visitati da sonde interplanetarie terrestri. Ora erano sulla via per lasciare il sistema solare. Nel febbraio 1997, all’epoca della nostra visita, la distanza dalla Terra era tale che ci voleva quasi un giorno per ricevere una risposta ad un segnale mandato da terra, e una unità di telemetria impiegava quattro ore per essere ricevuta completamente.

Molto interessante fu anche la riunione con il team di Mars Pathfinder, che era stato lanciato pochi mesi prima, e sarebbe arrivato e atterrato su Marte nel luglio dello stesso anno, rinverdendo i successi dei Viking, i due moduli di atterraggio della NASA che negli anni Settanta avevano effettuato un atterraggio morbido sulla superficie del pianeta rosso e trasmesso una grande mole di dati e una serie di immagini spettacolari. Pathfinder era una missione a basso costo, molto innovativa, e l’architettura del suo software di bordo assomigliava molto a quella che volevamo implementare noi su Rosetta.

In quei giorni intensi parlammo un po’ con tutti e di tutto al JPL, facendo domande di ogni genere, e piano piano definendo nella nostra mente i concetti di base che avremmo dovuto applicare nella preparazione di Rosetta. Raccogliemmo informazioni, impressioni, suggerimenti, esperienze e anche quello che gli americani chiamano lessons learned, cioè le cose che l’esperienza negativa ha insegnato a non rifare, o a fare in modo diverso.

Il nostro rapporto finale, che conteneva i resoconti dettagliati di tutte le riunioni e discussioni con gli esperti del JPL, ed elencava una serie di raccomandazioni che proponevamo di implementare per Rosetta, divenne all’ESOC una specie di best seller negli anni a venire. Ancora oggi c’è qualcuno che ne sente parlare per la prima volta e viene a chiedermene una copia. Oggi questo rapporto è una specie di documento storico, ma per noi del team di Rosetta leggerne le conclusioni, più di vent’anni dopo, è sorprendente, perché vi riconosciamo principi e strumenti che nel frattempo sono diventati una cosa ovvia, di applicazione e uso comune nel mondo odierno delle operazioni interplanetarie. Leggerle in questo rapporto mostra quanto pionieristico fu allora il lavoro di definizione e di preparazione delle operazioni di Rosetta. Quanto ancora avevamo da imparare.

Il progetto prende forma

Intanto le riunioni con i nostri colleghi di Friedrichshafen e Tolosa entravano sempre più nei dettagli del progetto. Erik Sørensen e io venivamo dalla scuola di Eureca, un satellite molto innovativo per i suoi tempi, con un’architettura dell’avionica e del software di bordo molto avanzata. Per la prima volta veniva utilizzata in un satellite dell’ESA la telemetria a pacchetti, un sistema nuovo e flessibile che avrebbe poi rivoluzionato il modo di gestire le informazioni provenienti da un satellite, permettendo un utilizzo molto più efficiente della banda di trasmissione. Questo ci aveva costretti a progettare sistemi di controllo a terra completamente diversi, più dinamici e flessibili, per la gestione dei dati di telemetria che arrivavano dalla piattaforma. Erik era responsabile di questi nuovi sistemi, e aveva progettato una nuova architettura che è usata ancora oggi per tutti i satelliti controllati dall’ESOC. Poi Eureca aveva un livello di autonomia a bordo assolutamente innovativo rispetto agli altri satelliti del suo tempo. Il software di bordo era costruito sulla base di moduli funzionali indipendenti che gli operatori potevano configurare per monitorare automaticamente qualsiasi parametro di telemetria, e attivare delle azioni precise in caso di necessità. Le funzioni automatiche potevano essere programmate e modificate abbastanza facilmente da Terra, tramite un linguaggio di programmazione compilato che non interferiva con le altre funzioni di software. Questa architettura dava per la prima volta al controllo missione in volo una serie di strumenti molto potenti e flessibili per gestire l’automazione e adattarla durante la missione.

Noi eravamo convinti che questa fosse la soluzione ideale anche per Rosetta: una missione di lunga durata nello spazio profondo, a distanze che non permettevano al controllo missione di intervenire in tempo reale nelle operazioni della sonda, doveva essere gestita a bordo da un sistema autonomo e facilmente riconfigurabile come quello di Eureca. Fu così che Erik e io – insieme a Jürgen Fertig, che di avionica e sistemi di gestione dati a terra non si occupava, ma aveva una buona conoscenza ed esperienza di sistemi di controllo di assetto dei satelliti – cominciammo, verso la fine degli anni Novanta, a spiegare ai nostri partner industriali come secondo noi doveva essere progettata la sonda, in modo da poter essere operata in maniera flessibile e sicura una volta in volo nello spazio.

Non furono anni facili. Rosetta era una missione totalmente nuova. Nessuno aveva mai costruito in Europa una sonda che dovesse volare nel vero spazio profondo, a distanze dal Sole e dalla Terra che nessuna sonda con pannelli solari aveva mai osato raggiungere nella storia dell’esplorazione del sistema solare. I nostri colleghi dell’industria partirono da una struttura esistente per satelliti per telecomunicazioni, le attaccarono i pannelli solari più grandi che si potessero sostenere con i limiti di peso e di dimensioni della sonda e, siccome i 64 m² di celle tradizionali non sarebbero mai bastati per mantenere in vita la sonda a 800 milioni di chilometri dal Sole, cominciarono a sviluppare celle speciali, che chiamarono LILT (bassa intensità e bassa temperatura), che funzionassero in tali condizioni ambientali estreme.

Fin qui tutto bene. Le divergenze di opinioni sorgevano soprattutto sull’architettura del software: mentre l’Astrium, per ovvie ragioni di robustezza e contenimento dei rischi, proponeva di usare architetture già sviluppate per i loro tradizionali satelliti di osservazione della Terra, noi insistevamo sulla più moderna architettura di Eureca e sulla necessità di costruire un sistema modulare e adattabile nelle varie condizioni della missione e alle possibili situazioni impreviste che in un decennio di volo avremmo sicuramente incontrato. Lo stesso succedeva con l’architettura della banca dati e con i concetti di sistema che dovevano risolvere i problemi posti dalle fasi di missione più complesse e critiche.

Gli ultimi anni Novanta furono un periodo di discussioni intense, di riunioni interminabili fino a tarda serata – tanto che dopo gli incontri facevamo fatica a trovare ristoranti ancora aperti a Tolosa! Ovviamente ciascuno aveva le sue buone ragioni e soprattutto i vincoli con cui doveva lavorare ed entro cui poteva negoziare. Noi, però, eravamo quelli che avrebbero subito tutte le conseguenze, per i due decenni successivi, di ogni soluzione di compromesso adottata, quelli che avrebbero dovuto risolvere i problemi generati dalle scelte e decisioni sbagliate prese in questi primi anni di progetto. Noi eravamo quelli che dovevano portare questa sonda alla cometa, attraverso un viaggio di sette miliardi di chilometri nello spazio interplanetario, per cui ci sentivamo in qualche modo dalla parte della ragione. «Noi siamo i buoni», ripetevo ai miei colleghi durante le riunioni del nostro team all’ESOC. «Se non per vocazione, almeno per necessità».

Erik e io ci occupavamo delle lunghe riunioni a Tolosa sul software di bordo e l’architettura dell’avionica, soprattutto per quanto riguardava la gestione dei dati, del traffico di comando e controllo a bordo, dell’autonomia. Quando si entrava in discussioni legate al controllo di assetto, Jürgen si univa a noi.

Presto dovemmo abbandonare alcune nostre idee, così Erik e io decidemmo che bisognava concentrarsi e riunire le forze per difendere le funzionalità che ritenevamo irrinunciabili per il controllo della missione: struttura a file (che chiamammo packet stores) per la memoria di massa, con la possibilità di gestirne la trasmissione a terra in modo indipendente e parallelo; possibilità di creare delle funzioni software indipendenti, senza integrarle nel software di bordo, che fossero facilmente modificabili e che permettessero di eseguire autonomamente a bordo tipiche procedure di controllo; un servizio di comandi a tempo che fosse flessibile e potente; infine un semplice e robusto protocollo di trasferimento di files di comandi da terra alla sonda, che permettesse un uso efficiente e sicuro del canale di comando alle distanze interplanetarie, senza attendere la conferma di ogni passo nella telemetria del satellite. Su queste funzioni lottammo a lungo, accettando compromessi solo nei dettagli, ma difendendone strenuamente la necessità. Almeno sul protocollo di trasferimento di files non ci furono conflitti: nella settimana prima di Natale del 1998 Astrium ci mandò la prima definizione del protocollo, basata sui requisiti che Erik e io avevamo inventato da zero. Erik era già in vacanza a Cipro e io volevo assolutamente che commentasse il documento di Astrium prima di una teleconferenza fissata per il 23 dicembre. Gli mandai le poche pagine del documento per fax in hotel e mi misi d’accordo per una telefonata preliminare nel tardo pomeriggio. Intanto lessi la proposta di Astrium e, con grande sorpresa, non riuscii a trovarvi niente di sbagliato o mancante. Possibile che fossimo d’accordo fin dall’inizio? Forse mi era sfuggito qualcosa? Pensai che in questo caso Erik avrebbe sicuramente trovato qualche problema e me lo avrebbe indicato la sera al telefono. Quando riuscii a mettermi in comunicazione con lui le nostre prime frasi furono molto caute: nessuno di noi due voleva ammettere di non aver trovato alcun problema fondamentale, che la proposta di Astrium era proprio buona! Insomma, per la prima volta passammo le vacanze di Natale un po’ più rilassati, con la sensazione di avere finalmente imboccato la strada giusta.

Invece le difficoltà continuarono. Dovemmo lottare per ottenere una funzionalità decente per le OBCP (le procedure di controllo da eseguire automaticamente a bordo), per la mission timeline (il sistema per l’esecuzione di comandi a tempo), per l’interpretazione della telemetria a bordo, per la struttura e la funzionalità della memoria di massa. Tutte discussioni che, cominciate nelle riunioni iniziali, proseguirono fino alle prime consegne del software di bordo, che poi andava corretto e modificato.

A volte la tentazione di lasciar perdere era forte, ma non potevamo: sapevamo che per una missione come Rosetta era indispensabile ottenere un progetto di software flessibile e robusto. Non potevamo mandare una sonda a un miliardo di chilometri dalla Terra senza poterla configurare per sopravvivere e reagire da sola, nello spazio profondo, almeno ai possibili guasti più gravi che potevano avvenire in qualsiasi momento durante la lunga missione. E poi la grande distanza ci permetteva solo di trasmettere a terra quantità bassissime di dati, a una velocità di trasmissione che poteva arrivare al massimo a qualche decina di kilobit al secondo. Per cui il controllo della telemetria da trasmettere doveva essere intelligente e flessibile, in modo da risparmiare al massimo l’utilizzo della banda di trasmissione per trasmettere dati ingegneristici, e lasciare più spazio possibile ai dati scientifici. Dopotutto era per la scienza che avremmo mandato Rosetta nel suo lungo viaggio verso la cometa.

Fu solo con l’avvicinarsi del lancio e con l’esecuzione di test dettagliati e congiunti con i colleghi dell’industria che piano piano le nostre posizioni si avvicinarono. Cominciavamo a capirci meglio, a valutare meglio i problemi dell’altra parte. Iniziava a formarsi un team unico, anche con i colleghi di Tolosa, che ci avrebbe accompagnato per tutti gli anni a venire.

Mentre a Tolosa si discuteva di software, di autonomia, di gestione della memoria di bordo e di specifiche per i sensori di assetto come i giroscopi, gli accelerometri, i sensori stellari, a Friedrichshafen i temi di discussione erano principalmente legati alle lunghe fasi di crociera, e al livello di autonomia della sonda per poterle gestire in modo efficiente e sicuro. La modalità operativa di Rosetta durante la lunga crociera iniziale fino a dopo il secondo sorvolo della Terra, quando le distanze dal Sole non sarebbero state eccessive (sotto le 3 unità astronomiche, cioè circa 450 milioni di chilometri) era stata chiamata dai colleghi di Astrium near sun hibernation mode (NSHM), ovvero “modalità di ibernazione vicino al Sole”. La discussione era più ideologica che altro: l’Astrium tendeva a voler mettere la sonda in uno stato di quasi ibernazione per spegnere quante più unità di bordo possibile e prolungare così la durata della loro vita nello spazio. Noi eravamo scettici sulla capacità della sonda di sopravvivere da sola e a lungo in uno stato del genere, senza il supporto di terra, e chiedevamo di essere convinti che i rischi fossero contenuti in modo adeguato. Il problema era che il satellite avrebbe dovuto mantenere il controllo di assetto almeno su due direzioni, per poter garantire il puntamento continuo dei pannelli solari verso il Sole. Questo implicava tenere attivi vari sensori e attuatori e aumentava i rischi che qualcosa andasse storto, e quindi richiedeva controlli periodici da Terra. Astrium puntava a riattivare il contatto con la Terra per effettuare controlli solo una volta ogni sei mesi, ma presto divenne chiaro che con una periodicità così scarsa i rischi sarebbero stati troppo elevati, e si cominciò a parlare di controlli ogni tre mesi.

Un’altra discussione collegata alla cadenza dei controlli riguardava l’opportunità o meno di accendere periodicamente le ruote di reazione inerziali. Questi strumenti, che servono per il controllo dell’assetto, sono delle pesanti ruote metalliche, del diametro di qualche decina di centimetri, montate all’interno del corpo del veicolo spaziale, che ruotano ad altissima velocità – alcune migliaia di giri al minuto – e sono azionate da un motore elettrico controllato dal computer di bordo che controlla l’assetto della sonda. Variando la velocità di rotazione della ruota il computer può generare una reazione che fa ruotare lentamente il corpo della sonda nel senso opposto, semplicemente usando il principio di azione-reazione della meccanica newtoniana. L’assetto può essere così controllato con altissima precisione, e senza bisogno di usare i propulsori di bordo. Essendo dei meccanismi sollecitati di continuo (ogni meccanismo è visto nel mondo della tecnologia spaziale come un punto debole per la sua alta probabilità di guasto irreparabile in volo), su una missione lunga la raccomandazione dei progettisti è di risparmiarli al massimo, cioè di tenerli spenti ogni volta che ce lo si può permettere. La discussione ideologica era: se le ruote stanno spente troppo a lungo potrebbero rovinarsi al momento dell’accensione successiva. Quindi bisogna trovare un periodo massimo di spegnimento e programmare un’accensione di prova periodica, il che ovviamente influenzava il periodo massimo di isolamento di Rosetta dal controllo di terra. Lo spegnimento delle ruote generava poi un ulteriore problema: senza le ruote funzionanti serviva un altro metodo per controllare l’assetto della sonda. L’alternativa più ovvia era usare i piccoli propulsori a reazione di cui Rosetta era dotata per un controllo più grossolano dell’assetto e per le manovre orbitali. La sonda ne aveva 24, due serie ridondanti di dodici propulsori da 10 Newton. Solo che anche questi sistemi sono delicati, possono guastarsi, e alla fine necessitano di controlli periodici ancora più frequenti.

Insomma, dopo anni di discussioni, di calcoli, di previsioni più o meno ingegneristiche, si giunse alla definizione di una modalità NSHM che comportava un controllo di assetto con i propulsori, un puntamento molto meno preciso che limitava le comunicazioni con la Terra e l’obiettivo di passare in questa modalità la maggior parte del tempo in crociera tra un evento critico e l’altro, con controlli periodici una volta al mese. A questo punto la discussione si spostò su come implementare nel software di bordo e nelle funzioni di controllo da terra questa modalità speciale di pseudo ibernazione. Ma per questo c’era tempo prima del lancio, il software non era ancora stato definito e le polemiche furono sospese per un po’ di tempo.

Ancora più difficile fu la discussione su come configurare Rosetta in modo che sopravvivesse alla terribile fase della missione quando avrebbe raggiunto la distanza massima dal Sole (circa 800 milioni di chilometri) e l’energia dei pannelli solari non sarebbe stata sufficiente ad alimentare tutti i sistemi elettrici di bordo. A quel tempo la sonda con pannelli solari che deteneva il record di distanza dal Sole era Stardust della NASA, che aveva volato a poco più di 400 milioni di chilometri. Rosetta doveva quasi duplicare questa distanza record, e i pannelli solari che montava, capaci di 8 kW di potenza vicino alla Terra, avrebbero prodotto poco più di 600 W alla distanza massima dal Sole. Con questa potenza elettrica non si potrebbe far funzionare nemmeno un piccolo elettrodomestico come un forno a microonde, per non parlare di aspirapolvere, ferro da stiro o lavatrice, che consumano da tre a quattro volte tanto! Insomma, l’energia elettrica disponibile a quasi 800 milioni di chilometri dal Sole era appena sufficiente a tenere attiva la sonda, ma non era sufficiente nel caso di problemi, come un degrado dei pannelli solari, la perdita di una stringa di celle solari o una situazione di safe mode, cioè quando qualche problema a bordo fa scattare una sequenza automatica di azioni che mette la sonda intera in modalità di funzionamento sicuro e stabile, in attesa di ordini da terra (a dire la verità c’era potenza elettrica per entrare in safe mode, ma non abbastanza per uscirne...).

La soluzione più ovvia, proposta e difesa strenuamente dai colleghi dell’Astrium, era di spegnere la sonda completamente o quasi. L’idea era di mettere la sonda in rotazione attorno a un asse che tenesse i pannelli solari puntati in direzione del Sole per la durata della fase di massima distanza, cioè quando la sonda si trovava oltre le 4,5 unità astronomiche, circa 675 milioni di chilometri dal Sole. E poi spegnere tutto il possibile per minimizzare il consumo di elettricità a bordo, a cominciare dal sistema di controllo di assetto, il computer principale, la memoria di massa e ovviamente il trasmettitore del segnale radio verso la Terra. La poca elettricità generata dai pannelli solari a quelle distanze estreme dal Sole, intorno all’orbita di Giove, andava riservata ai riscaldatori termostatici che sarebbero serviti a mantenere la temperatura minima per evitare che il satellite e il suo propellente liquido nei serbatoi congelassero. Questo significava passare un periodo di circa due anni e mezzo con la sonda abbandonata a se stessa, senza contatto con la Terra, senza controllo di assetto attivo, senza reazioni automatiche a guasti a livello di sistema (che sarebbero state insostenibili da gestire senza il supporto da terra entro un tempo breve).

Naturalmente questo era uno scenario agghiacciante per noi del controllo missione: due anni e mezzo senza contatto con la sonda! Abbandonata nel gelo dello spazio profondo senza la possibilità di intervenire da terra! E questo prima di avere raggiunto la cometa e aver condotto la missione scientifica principale. No, era una follia, l’ESA non poteva accettare di correre un rischio simile con la missione più importante di tutto il programma scientifico. Ci doveva essere un’altra soluzione. Nessuno nella storia del volo interplanetario aveva mai progettato una missione che dovesse passare per una fase di ibernazione prima di aver raggiunto l’obiettivo. Anche i nostri colleghi americani, alla cui leggendaria esperienza ci dovevamo inchinare, ci avevano detto che eravamo pazzi ad accettare un tale rischio.

Questo pensavo in quel periodo. Ero convinto che avremmo trovato la soluzione prima di imbarcarci in una missione così rischiosa. Ma la soluzione non si trovava. Mancava sempre qualche watt di potenza per riuscire ad alimentare una delle infinite configurazioni che provammo a definire. Oppure appariva un nuovo possibile guasto che non avevamo considerato prima e che rendeva la nostra soluzione inaccettabile. Continuammo la discussione e i tentativi, insieme ai colleghi dell’Astrium, per almeno due anni. Alla fine, in una drammatica riunione all’ESOC nell’estate del 2000, dovetti gettare la spugna: l’ibernazione completa della sonda – il cosiddetto deep space hibernation mode (DSHM), o ibernazione nello spazio profondo – venne accettata come l’unico modo di compiere la missione, di raggiungere la nostra cometa. Nella stessa riunione decidemmo però, su mia insistenza, di introdurre un test in volo di tale modalità operativa. Il test comportava il mettere la sonda in rotazione per qualche giorno in un periodo in cui era ancora relativamente vicina alla Terra e il segnale radio con le stazioni non avrebbe dovuto essere interrotto, permettendoci di monitorare, misurare e caratterizzare il comportamento dinamico della sonda in questa configurazione. Ricordo che Alois Eibner, ingegnere di sistema per Rosetta all’Astrium, dopo aver passato tutta la riunione a tentare di convincermi che la modalità DSHM era sicura e i rischi molto limitati, non voleva accettare l’idea di fare un test in volo: «È troppo rischioso!» mi diceva. E questo certo non mi aiutava a tranquillizzarmi...

Avevo dovuto accettare mio malgrado l’ibernazione, ma ero ancora sicuro che, una volta in volo, tutti si sarebbero convinti che era un concetto troppo rischioso e avremmo trovato insieme una soluzione più accettabile. Tanto più che normalmente prima del lancio tutti si tengono margini di risorse, compresa la potenza elettrica, che poi vengono utilizzati una volta che in volo ci si rende conto di essere stati troppo conservatori. Ero fiducioso che alla fine non avremmo mai ibernato Rosetta. Mi sbagliavo, e in effetti i primi anni di volo contribuirono presto a farmi cambiare opinione.

Intanto anche Mark Sweeney aveva le sue difficoltà. Il suo compito era di parlare con i vari team che stavano progettando e costruendo gli strumenti scientifici che Rosetta avrebbe portato alla cometa, da una parte cercando di capire i dettagli del loro funzionamento e dall’altra spiegando che tipo di funzioni e interfacce servivano a noi delle operazioni per essere in grado di controllare lo strumento durante il volo. Insieme a Mark sviluppammo una specie di questionario, che lui sistematicamente esponeva agli scienziati e tecnici di ogni team, sparsi per l’Europa, tornando con l’informazione che ci serviva. Molti viaggi in luoghi abbastanza inusuali e per noi quasi esotici, mentre io, Erik e Jürgen facevamo la spola tra ESOC, Tolosa e Friedrichs­hafen. Nicky invece si occupava della banca dati, lo strumento essenziale per il nostro sistema di controllo: la sorgente di tutti i dettagli che permettono di decodificare ogni pacchetto, ogni parametro di telemetria ricevuto dal satellite, interpretarlo e visualizzarlo sugli schermi, monitorarlo e anche elaborarlo in parametri derivati, se serve; e di tutti i telecomandi che si possono mandare al satellite per controllare le sue funzioni, configurarlo, azionare ogni possibile meccanismo software e hardware. La banca dati viene gestita inizialmente dall’industria che deve integrare e testare la sonda. Poi viene passata all’ESOC che la completa per poter far funzionare la sonda nello spazio. Noi volevamo che dall’inizio la banca dati contenesse informazioni totalmente compatibili con quelle che sarebbero servite al nostro sistema di controllo, senza troppe conversioni e soprattutto senza interventi manuali nel processo di importazione. Un lavoro delicato, dove i problemi si vedono solo quando si va nel dettaglio. Nicky era la persona giusta per questo. Esperto di banche dati e dei nostri sistemi di terra, era anche molto puntiglioso e cocciuto, ma riusciva sempre a restare di buon umore anche nei momenti più pesanti, quando non ci si riusciva ad accordare con i progettisti dell’industria o quando gli stessi non volevano capire i nostri problemi e requisiti.

In questi anni iniziali di discussioni, conflitti, compromessi, viaggi e riunioni che duravano fino a tarda sera sono state poste le basi per la missione, per il progetto della sonda e per quello dei nostri sistemi di terra. Non sempre soluzioni ideali, ma comunque una serie di strumenti che hanno formato l’architettura e l’infrastruttura interplanetaria dell’ESA, sia per quanto riguarda le sonde che per tutti i sistemi di terra. Partiti da zero nel 1996, questi sono stati gli anni più importanti non solo per la missione Rosetta, ma anche per tutte le missioni scientifiche e in particolare interplanetarie che sono seguite.