Costruire il futuro

A partire dal 1999 il tempo delle interminabili diatribe concettuali su come progettare la missione, la sonda, i sistemi di terra era stato esaurito: il lancio era ormai distante poco più di tre anni e adesso si doveva passare davvero dalla fase di progettazione a quella di costruzione, integrazione e collaudo. E per me si trattava di entrare in una fase nuova, in cui non bastavamo più noi del nucleo storico a fare tutto il lavoro di preparazione: ora si trattava di ingrandire il team in modo che potesse sopportare il carico di lavoro che sapevamo sarebbe cresciuto rapidamente e continuamente fino al lancio.

Il team di controllo della missione cresce

Nella seconda metà degli anni Novanta l’ESA era in una situazione difficile per quanto riguardava il suo budget. In particolare il programma scientifico doveva assorbire i costi risultanti dalla perdita della missione Cluster e la decisione presa l’anno successivo di ricostruire e rilanciare i quattro satelliti distrutti sull’Ariane 5 nel giugno 1996. Il budget per questa ricostruzione non era ovviamente nel piano finanziario a lungo termine del programma scientifico. Ma il periodo di crisi era generale nell’ESA, e noi all’ESOC in aggiunta dovevamo far fronte alla decisione di Eumetsat di non far più controllare da noi la loro flotta di satelliti, ma di costruire un loro centro di controllo indipendente a pochi passi dall’ESOC. Mettendo questi eventi insieme il carico di lavoro per il nostro centro di controllo in quegli anni era diminuito improvvisamente e drasticamente. Così mentre molti dei nostri colleghi, preoccupati dalla situazione, lasciavano l’ESOC o addirittura l’ESA alla ricerca di altre direzioni per le loro carriere, noi non avevamo né il budget né il permesso per assumere rimpiazzi adeguati.

Verso metà del 1999 il mio profilo di spesa prevista mi avrebbe permesso finalmente di assumere ulteriori membri del team di operazioni, coloro che mi avrebbero affiancato nelle ultime fasi della preparazione della missione, quelle più intense dal punto di vista del carico di lavoro. Potevo pescare nel serbatoio di ingegneri contrattisti, cioè forniti dalle ditte europee che lavoravano con noi in supporto alle missioni dell’ESOC. Per prima cosa, però, avevo bisogno di nominare un mio vice, che doveva appartenere al personale dell’ESA. Insieme a Manfred stavamo analizzando i possibili candidati nell’ambito dei colleghi che già lavoravano all’ESOC quando, verso la metà dell’anno, la dirigenza dell’ESA mi autorizzò ad assumere dall’esterno un nuovo ingegnere nel team. Era l’occasione che aspettavo: ora potevo davvero scegliere la persona giusta in una rosa di aspiranti potenzialmente vastissima, dato che il posto era aperto a candidati provenienti da tutta Europa. Cominciai a discutere con i miei capi diretti sull’approccio da prendere. L’ESOC aveva parecchi ingegneri esperti di operazioni di satelliti che lavoravano come contrattisti su altri progetti, molti dei quali sarebbero stati certamente molto utili nel team, specialmente in quel momento. Avevamo anche un paio di ingegneri dell’ESA che avrebbero potuto da subito prendere il ruolo di mio vice nel team delle operazioni. Il problema era che tutti questi soggetti non erano solo ottimi esperti, ma avevano la mia età o erano anche più anziani. Io stavo ormai per compiere 40 anni, il lancio sarebbe avvenuto tre anni e mezzo dopo e l’arrivo a Wirtanen, la nostra cometa, era previsto per il 2012, oltre tredici anni più tardi. Ero fermamente convinto che il mio team dovesse essere basato su una nuova generazione di ingegneri e scienziati che, mescolati con me e gli altri più esperti e anziani del “nucleo storico” di Rosetta, avrebbero assorbito la nostra conoscenza, fatto esperienza sotto la nostra supervisione e nel corso degli anni portato avanti la missione anche senza di noi.

L’ESOC è un ambiente piuttosto conservatore, così come lo sono tendenzialmente gli operatori spaziali, che hanno a che fare con il controllo di veicoli costosissimi e lontani che non perdonano il più piccolo errore umano. I miei capi di conseguenza facevano resistenza. Alan Smith, che al tempo era il capo della divisione responsabile delle operazioni di missione, e come tale aveva il controllo su tutte le assunzioni nel nostro settore, sia di personale dell’ESA che di contrattisti, non accettava l’idea di assumere ingegneri giovani e inesperti per la missione più importante del decennio a venire. Ma la mia insistenza, appoggiata come al solito incondizionatamente da Manfred – che, come abbiamo visto, sapeva essere molto convincente –, fu premiata con l’assunzione di un giovane ingegnere aerospaziale italiano di 29 anni, Andrea Accomazzo. Piemontese della Val d’Ossola, con un breve passato nell’aeronautica militare, Andrea aveva cinque anni di esperienza nell’industria aerospaziale ed anche una certa familiarità con Rosetta, dato che aveva lavorato per qualche tempo sui progetti iniziali del modulo di atterraggio. Ovviamente non conosceva niente di operazioni spaziali, ma questo per me non era assolutamente un problema, né costituiva un criterio di scelta. Anzi, presentava dei vantaggi: avrei potuto “iniziarlo” al nostro lavoro senza dover prima eliminare eventuali pregiudizi o esperienze precedenti che potevano non coincidere con quello che serviva a una missione come Rosetta. Era chiaramente un ragazzo sveglio e molto motivato. Questo, secondo me, lo rendeva il candidato ideale, da addestrare al mondo delle operazioni quasi da zero, passandogli gradualmente la mia esperienza operativa accumulata nei quindici anni precedenti. Andrea entrò nel mio team nel luglio 1999, e già dopo pochi mesi cominciò ad accompagnarmi a tutte le riunioni con l’industria, a Friedrichshafen, e soprattutto a Tolosa, imparando rapidamente tutti i dettagli tecnici del progetto della sonda, e soprattutto quelli rilevanti per il suo funzionamento e le operazioni di volo in generale. Lo indirizzai subito verso l’avionica e il software di controllo, una funzione fondamentale per le operazioni e per le interfacce con i sistemi di terra. Nel giro di qualche tempo, mi resi conto con soddisfazione che Andrea mi aveva già superato nella conoscenza dei dettagli del funzionamento dei sistemi di bordo. Avevo raggiunto il mio obiettivo.

Quasi contemporaneamente all’assunzione di Andrea mi si presentò l’occasione di attingere al programma dell’ESA chiamato Young Graduate Trainees, YGT, uno schema di grande successo per la formazione professionale di giovani laureati senza esperienza di lavoro significativa. All’ESOC venivano assegnate due volte all’anno poche posizioni di YGT, molto ambite internamente perché con un impegno relativamente basso fornivano al tutore la possibilità non solo di avere un anno di manodopera senza costi per il progetto, ma soprattutto di investire in giovani laureati, di solito molto brillanti, che spesso poi venivano successivamente assorbiti dalle ditte di contrattisti che ci fornivano personale specializzato per i nostri team di operazioni.

Tra i candidati per la posizione su Rosetta c’era una giovane donna, Elsa Montagnon. Francese, ingegnere, 23 anni ancora da compiere, quando si presentò al colloquio Elsa aveva già un po’ di familiarità con l’ESOC, avendo fatto uno stage di qualche mese con Wolfgang Wimmer, il mio primo capo sezione dei tempi di Eureca, una specie di leggenda delle operazioni spaziali europee, dato che aveva lavorato a tutte le missioni controllate dall’ESOC fin dagli inizi della sua storia, nel 1967, e che ora nel nostro dipartimento si occupava degli studi per le missioni future. Io non feci nemmeno parte della commissione che selezionò gli YGT da assumere nell’estate del 1999. Elsa era tra i candidati più giovani, ma impressionò tutti i colleghi della commissione con il suo approccio strutturato ai problemi e la sua capacità di pensare in modo critico. Fu Wolfgang stesso, che la conosceva, ad annunciarmi con il suo solito entusiasmo contagioso che Elsa sarebbe stata la mia futura YGT. Visto che non mi aveva ancora incontrato, poche settimane prima di cominciare formalmente a lavorare all’ESOC nel mio team Elsa chiese un appuntamento e venne all’ESOC per presentarsi al suo futuro tutore. All’ora prevista per l’incontro, davanti alla porta del mio ufficio, che all’epoca era in una specie di budello tra l’edificio E, dove si trovavano le sale controllo, e l’edificio F, dove c’era la maggior parte degli uffici del dipartimento, vidi apparire due persone: Elsa era venuta accompagnata da sua madre! Dopo una piccola esitazione, che le due donne fecero educatamente finta di non aver notato, le invitai a entrare nel mio piccolo ufficio e le feci sedere. Così, cercando di nascondere l’imbarazzo e borbottando ogni tanto qualche parola nel mio francese meno che scolastico, feci il mio discorso introduttivo (in inglese) a Elsa sotto lo sguardo severo della madre, che sentivo fortemente investigarmi e giudicarmi. Evidentemente passai l’esame, dato che Elsa in effetti si presentò all’ESOC nel giorno stabilito poco tempo dopo e si installò nell’ufficio al primo piano dell’edificio F, proprio di fronte all’ufficio del capo dipartimento. Ancora oggi quella stanza viene a volte usata per gli YGT, e ogni giorno entrando nel mio ufficio vedo i nuovi giovani ingegneri del dipartimento e penso a quanti ne sono passati dal 1999, quando accadevano questi fatti.

Siamo abituati al fatto che i nostri YGT siano persone di grande valore, intelligenti, preparati, motivati ed entusiasti. Ma non ci volle molto ad avere la conferma che Elsa era tra quelli più promettenti non solo per crescere nel mio team, ma anche per una rapida carriera nell’Agenzia. Incredibilmente disciplinata e organizzata, lavorava sodo e non aveva nessuna remora a dire quello che pensava, ma soprattutto quando lo diceva era sempre preparata a difendere la sua opinione con fatti e ragionamenti. Per il suo anno di addestramento all’ESOC le assegnai il compito di analizzare per la prima volta gli aspetti operativi delle fasi critiche principali della “crociera” verso la cometa. Affrontò il suo incarico molto professionalmente, nonostante la mancanza di esperienza di lavoro, e prima della fine del suo periodo come YGT aveva prodotto la prima versione di una serie di documenti tecnici che avrebbero formato negli anni successivi la base per la preparazione delle procedure operative e le cronologie di ogni fase critica, come gli incontri previsti con i pianeti o con gli asteroidi. La cosa che trovavo impressionante nel lavorare con Elsa era che, una volta affidatole un compito, si metteva a lavorarci in modo assolutamente indipendente e si ripresentava solo entro il tempo assegnatole, con il compito completato sì, ma in un modo che era molto simile a come lo avrei svolto io stesso. Sembrava capire immediatamente cosa volessi e come lo volessi. In varie occasioni arrivai seriamente a pensare che avesse poteri telepatici. Invece era semplicemente un’ascoltatrice eccezionalmente attenta, con una capacità di elaborazione delle informazioni raccolte e delle istruzioni ricevute estremamente precisa e completa. Il tutto corredato naturalmente da un’intelligenza molto viva.

Dopo pochi mesi mi resi conto che Elsa poteva essere un elemento molto importante per il team che volevo costruire. Ma aveva un contratto di un anno, dopo di che bisognava trovare il modo di assicurarsi che continuasse a lavorare su Rosetta. Nell’estate del 2000, proprio poche settimane prima che il contratto di YGT di Elsa scadesse, capitò un evento che nella storia dell’ESOC non era mai successo, e che è rimasto unico: la divisione di Alan Smith, che raggruppava tutti gli ingegneri delle operazioni dell’ESA, ebbe il permesso di assumere in un colpo solo cinque nuovi ingegneri! Stavolta non mi feci sfuggire l’opportunità di partecipare alla commissione che avrebbe selezionato i cinque da assumere tra le centinaia di domande che ricevemmo. Tra tutti i responsabili di operazioni delle varie missioni ero quello che avrebbe approfittato maggiormente di questa ondata di assunzioni, visto che due dei cinque assunti avrebbero lavorato nel team di Rosetta. Invitammo quindici candidati, e alla fine per la posizione di Rosetta scegliemmo Elsa, nonostante la sua giovane età e la forte competizione con ingegneri più esperti. Per la seconda posizione, che era da condividere con il neonato team di Mars Express – la prima missione dell’ESA verso un altro pianeta, Marte, che doveva partire pochi mesi dopo Rosetta –, scegliemmo Peter Schmitz, un ingegnere tedesco che al tempo lavorava come contrattista nel nostro team di Ulysses al JPL, e portava così un po’ di esperienza di operazioni interplanetarie e di interfacce NASA nel nostro ambiente. Peter, però, avrebbe avuto inizialmente molto da fare su Mars Express, e avrebbe raggiunto il team di Rosetta solo qualche tempo dopo.

Alla fine del 2000 con Andrea ed Elsa nel team avevo ora due elementi fondamentali e giovani: Andrea era appena trentenne, mentre Elsa di anni ne aveva solo 24, la stessa età che avevo io quando, 17 anni prima, ero entrato per la prima volta all’ESOC di Darmstadt e nel mondo delle operazioni spaziali. Era solo il primo passo nel piano che avevo per costruire il team che poteva gestire il futuro della missione Rosetta nei quindici anni a venire, ma era un passo importante.

Nel frattempo, già dall’inizio dello stesso anno mi ero messo a cercare un esperto di software che potesse lavorare ai dettagli per il mantenimento del software di bordo. Di solito i nostri team di controllo missione non osano nemmeno toccare il software di bordo: questo è scritto principalmente a bassissimo livello, spesso con sistemi operativi speciali e antichi, scritti apposta per i satelliti, con lo scopo di ottimizzare l’utilizzo della memoria principale, che nei satelliti era a quei tempi ancora molto limitata (il computer principale di Rosetta aveva una memoria di un megabyte, che comparato a un telefonino di oggi non sarebbe nemmeno in grado di prendere una telefonata!). Per tutte le missioni sotto il controllo dell’ESOC la norma era che l’industria che aveva progettato il software di bordo fosse incaricata di modificarlo, se necessario, anche durante il volo. Anche in questo campo, però, la mia esperienza passata con Eureca mi aveva insegnato che nel caso di Rosetta sarebbe stato meglio adottare un approccio diverso, cioè cercare di acquisire abbastanza conoscenze sul soft­ware di bordo da permetterci di modificarlo “in casa”, ovvero all’interno del team di operazioni. Ciò avrebbe avuto il doppio vantaggio di aumentare la nostra conoscenza del funzionamento della sonda e di evitare di assegnare costosi contratti di supporto all’industria che, per una missione della durata di dodici anni, sarebbero stati insostenibili per il nostro budget.

Per poter essere indipendenti per il mantenimento in volo del software di bordo, però, ci serviva un esperto di software che sapesse mettere le mani nei livelli più nascosti del sistema operativo, giocare con i bit e i byte, capire e manipolare le interfacce tra il processore e le funzioni di firmware, conoscere uno per uno i registri di memoria e saperli usare e modificare. Già, ma dove lo trovavamo uno così all’inizio del nuovo millennio, nel pieno della nuova era in cui gli informatici ormai non si sporcavano più le mani con la programmazione in linguaggi come l’Assembler, che già consideravano antiquati i linguaggi tradizionali come C++, che storcevano il naso se non potevano usare un’interfaccia grafica per scrivere software? Dopo una ricerca di quasi sei mesi mi resi conto, come spesso succede, che la soluzione ce l’avevo sotto il naso: un giovane ingegnere spagnolo, José (Chema) Morales, che lavorava come contrattista all’ESOC nel settore di supporto IT dopo aver fatto esperienza prima in Spagna e poi anche come YGT all’ESOC. Chema non disdegnava di lavorare a diretto contatto con i livelli più profondi del software, non si vergognava a leggere i codici esadecimali, anzi non nascondeva un certo entusiasmo nel poter lavorare così vicino alla logica di base del “cervello” di una sonda interplanetaria. Io ascoltavo quello che diceva e provavo un grande sollievo nel vedere che c’erano ancora, nelle nuove generazioni, ingegneri a cui piaceva aprire le scatole per vedere come funzionavano. In più Chema parlava correntemente varie lingue, tra cui l’italiano, ed era giovane – a quel tempo appena venticinquenne. Ma era anche aperto, simpatico, spiritoso. Una specie di rarità nel mondo arido e deterministico degli esperti di programmazione software. Insomma: era la persona che faceva al caso nostro. Avevamo trovato il nostro OBSM engineer, cioè l’“ingegnere responsabile del software di bordo”.

Chema fu il primo contrattista che assunsi in quel periodo. In effetti altro personale ESA per il mio team non ne potevo più assumere. Mi potevo ritenere già molto fortunato, direi privilegiato, ad avere nel team, a tre anni dal lancio, due ingegneri ESA, più uno condiviso con Mars Express. Era una cosa eccezionale all’ESOC, e testimoniava quanto la dirigenza del centro si rendesse conto dell’importanza e criticità della missione Rosetta. Ad ogni modo il profilo annuale del nostro budget di missione, che avevo accuratamente studiato, calcolato e soprattutto difeso negli anni precedenti, mi permetteva di assumere altri ingegneri contrattisti che si sarebbero occupati dei vari aspetti della sonda, degli strumenti scientifici e dei sistemi di terra. Il team fu completato entro il 2001. Ci furono vari cambiamenti e aggiunte, che non starò a spiegare in dettaglio. Citerò solo due nuovi arrivi, perché mi aiutarono a completare le aree principali di specializzazione nel team, ma anche perché avranno un ruolo importante nel racconto degli anni successivi. Il primo era Ignacio Tanco, un esperto nel campo del controllo di assetto di satelliti, un ingegnere spagnolo che aveva lavorato negli USA sul progetto Iridium. Anche Ignacio era giovane, appena ventiseienne: un’altra scommessa per il futuro. Il secondo era Sylvain Lodiot: anche lui sotto i 30 anni, francese, esperto di informatica che aveva fatto esperienza all’ESOC nei sistemi di controllo delle missioni meteorologiche. Mi sarebbe stato molto utile per aiutarmi nella preparazione e collaudo dei sistemi software che stavamo sviluppando per il centro di controllo.

Alla fine del 2001 il core team di Rosetta era ormai formato. Potevo essere soddisfatto: avevo un misto di esperti sui 40 anni di età e di giovani brillanti intorno ai 25-30 anni. Il team era pronto non solo per lo sprint finale della preparazione al lancio, ma anche per la crescita ed evoluzione che mi ero prefigurato e che sarebbe inevitabilmente avvenuta negli anni del lungo viaggio verso la cometa.

Gli anni dell’integrazione

Il lavoro sul segmento di terra, cioè tutti i sistemi che ci sarebbero serviti per controllare Rosetta nel suo lungo viaggio nello spazio, passò, verso il cambio di millennio, dalla fase concettuale di definizione e di consolidamento dell’architettura alla fase di sviluppo e poi presto a quella di test. Furono anni di lavoro intenso, di giornate lunghissime e anche di difficoltà e frustrazioni. Ma finalmente cominciavamo ad avere qualcosa tra le mani, i sistemi di controllo, le nuove interfacce con le stazioni di terra, da provare, verificare, testare, e infine da usare per tutte le attività di preparazione.

All’inizio del 2001 la nostra nuova sala controllo era pronta. Erano due sale separate, per essere precisi, entrambe al secondo piano dell’edificio D, dove avevamo spostato anche i nostri uffici. Una era grande, con una parete di vetro che dava su un ampio spazio vicino all’ingresso, venendo dalle scale, pensato per ospitare visitatori che avrebbero potuto osservare le attività all’interno della sala senza disturbare chi ci lavorava. Nella sala principale avremmo stabilito il controllo delle operazioni delle sonde interplanetarie, non solo Rosetta ma anche Mars Express, che nel frattempo era anch’essa in preparazione per un lancio nel giugno 2003, pochi mesi dopo quello di Rosetta. E poi, ovviamente, altre sonde future, se ce ne fossero state, come noi ovviamente speravamo. La seconda sala invece era piuttosto infelice, ricavata da uno spazio non proprio ideale a fianco della sala principale, in cui eravamo riusciti solo a far entrare quattro stazioni di lavoro allineate di fronte alle finestre che, per non sforzare troppo gli occhi degli operatori seduti davanti agli schermi dei computer, tenevamo quasi sempre oscurate. Questa sala era pensata come sala di supporto, per eseguire test a terra, e soprattutto per quelle fasi di attività in volo che avrebbero richiesto la presenza di vari operatori, per cui la gente avrebbe potuto disturbare le operazioni delle altre sonde se fossero rimasti nella stessa sala. Noi eravamo entusiasti delle nostre nuove sale controllo, sia di quella più grande, spaziosa e visibile, sia di quella più brutta e angusta, nascosta, al suo lato.

Fu in questa sala che, nel marzo del 2001, ci ritrovammo a provare per la prima volta in nuovo sistema di controllo sviluppato per Rosetta, basato su una versione del software di infrastruttura che fino ad allora era stata usata solo da un’altra missione, Integral, non ancora lanciata e comunque con requisiti molto più semplici di quelli di Rosetta. Ricordo il primo giorno, quando Andrea e io ci sedemmo davanti agli schermi di una stazione di lavoro, e io cominciai a digitare le istruzioni per connettermi al sistema di controllo, sotto lo sguardo un po’ nervoso di Alessandro Ercolani, il nostro collega di ESOC che seguiva lo sviluppo del software di controllo da parte dell’industria. L’esperienza fu devastante: non si riusciva ad aprire un singolo schermo alfanumerico, o almeno bisognava attendere minuti prima che cominciasse, lentamente, a mostrare i valori dei parametri di telemetria. Per non parlare di quando provai a chiedere il replay dei valori immagazzinati nel passato, solo qualche minuto indietro nel tempo: il sistema non ce la faceva e ricopriva Alessandro e i suoi colleghi di messaggi di errore, che loro ricevevano e osservavano costernati e impotenti sui loro schermi di controllo. Era evidente che il sistema non funzionava proprio e che c’era ancora molto da fare.

Il sistema di controllo di terra nei mesi successivi migliorò, permettendoci di eseguire i primi test in collegamento con la sonda, che si trovava a Torino, dove l’Alenia Spazio aveva il compito di integrare tutte le parti della sonda ed eseguire tutti i test a livello di sistema. Ma questi test cominciarono a rivelarci le difficoltà che anche la sonda stessa aveva con le prime versioni del software di bordo. Era evidente che anche l’Astrium aveva ancora parecchio da fare per completare il software di bordo e soprattutto renderlo sufficientemente robusto per affrontare le sfide di una lunga missione interplanetaria. Continuammo così ad aggiungere brevi test con la sonda stessa o con il modello ingegneristico, con il quale potevamo testare il nostro software e le reazioni di quello di bordo senza occupare prezioso tempo di integrazione sulla sonda vera e propria.

A metà settembre organizzammo una gita in montagna del team, durante il fine settimana. Era stata una mia idea, nata come conseguenza del fatto che le vacanze estive degli anni passati mi avevano ormai convinto che non sarei riuscito a far appassionare i miei figli alla montagna. A me invece le passeggiate in montagna d’estate mancavano. Così decisi di approfittare del fatto che avevamo un uomo di montagna nel team, Andrea, e gli proposi di organizzare, per quelli del team di Rosetta che avessero voluto partecipare, un fine settimana di passeggiate nella sua Val d’Ossola, con tanto di notti in rifugio. L’iniziativa ebbe successo, tanto che organizzammo due auto con dieci persone, con partenza venerdì 14 settembre. La settimana prima della partenza avevamo ottenuto un’altra opportunità della durata di un giorno per connetterci a Rosetta e testare i nostri sistemi, e il team lavorò duro per preparare e condurre il test e meritarsi il fine settimana in montagna.

Il giorno prima del test, l’11 settembre, ero nel mio ufficio a finalizzare la lista di procedure da eseguire e il piano di lavoro, quando mi chiamò Nestor Peccia, un collega italo-argentino che all’ESOC lavorava sui sistemi software di terra, dicendomi che c’era stato un incidente a New York: un aereo si era schiantato su una delle due torri del World Trade Center. La cosa mi sorprese molto, senza però allarmarmi più di tanto. E poi avevo altro da fare che preoccuparmi di un incidente aereo. Poco dopo entrarono in ufficio altri colleghi, molto spaventati, ripetendo la notizia di Nestor e aggiungendo che, poco dopo il primo, un altro aereo si era schiantato sulla seconda torre del World Trade Center. A questo punto era ovvio che non si trattava di un incidente. Guardai su internet per avere conferma della notizia e leggere ulteriori dettagli. C’era molta confusione e si capiva poco cosa stesse succedendo. Poi improvvisamente mi ricordai che nella sala riunioni D217, di fronte al mio ufficio, Manfred e altri erano riuniti con alcuni colleghi della NASA del JPL di Pasadena, per discutere su vari aspetti generici dell’interfaccia di supporto reciproco tra le due agenzie. Mi alzai, uscii dall’ufficio ed entrai nella sala riunioni, spiegando che stava succedendo qualcosa di molto grave a New York. I colleghi americani erano scettici. Uno di essi mi consigliò paternamente di non credere a tutto quello che appare su internet. Evidentemente già allora gli americani avevano la tendenza a bollare come fake news, come falsa, qualsia­si notizia non li aggradi. Manfred, che conoscendomi sapeva che non mi sarei mai permesso di propagare stupidamente una notizia allarmistica del genere senza aver controllato, si alzò e ci disse di seguirlo nel suo ufficio, che era accanto al mio, dove aveva un televisore. Lo accese e subito ci trovammo di fronte alle immagini irreali dei due grattacieli gemelli più alti di New York che bruciavano. Restammo stupefatti, sgomenti e in silenzio davanti a quelle immagini. Il commentatore stava dicendo che una delle due torri era crollata, e ci volle un po’ per renderci conto che in effetti stavamo vedendo, nel fumo e nella confusione, solo un grattacielo. L’altro non c’era più.

Quel giorno non riuscimmo più a fare molto. I nostri colleghi americani da quel momento cominciarono a contattare le loro famiglie, e poco più tardi anche le agenzie di viaggio, quando appresero che il traffico aereo sugli Stati Uniti era stato completamente bloccato. Ci misero una settimana o più, credo, prima di trovare un volo che li riportasse a casa. Io cercai di finire la preparazione del test dell’indomani, poi andai a casa e passai la serata incollato alla tv, come credo chiunque altro al mondo che possedesse un televisore. Il mattino dopo alle cinque stavo già guidando verso l’ESOC, dato che il test cominciava molto presto. Alla radio le notizie sull’evento del giorno prima erano ancora confuse e frammentarie. Noi passammo il giorno a eseguire i nostri test con Rosetta, automaticamente isolando le nostre menti da quello che stava succedendo nel mondo. Poi, due giorni dopo, partimmo per la gita in montagna. Temevo che avremmo sostituito i discorsi di lavoro con i commenti sugli attentati dell’11 settembre, invece avvenne esattamente il contrario. Camminare tra le montagne dell’alta Val d’Ossola, visitare paesini isolati di montagna che evidentemente non erano toccati per niente dalle vicende che avvenivano dall’altra parte del mondo, restare isolati dalle notizie per tre giorni, ci fece benissimo. Ricordo quella gita come un periodo sereno, con estenuanti ma piacevoli camminate in quota e serate fatte di mangiate e grandi risate a tavola fino a notte inoltrata. Fu la prima di una lunga serie di gite annuali in posti sempre diversi, che diventarono gradualmente sempre meno una passeggiata in montagna e sempre più una specie di turismo organizzato. Di volta in volta cambiavano i partecipanti, mentre il nucleo iniziale rimase sempre lo stesso, fedele alla tradizione che avevamo instaurato nel settembre del 2001. E così anche un evento di importanza mondiale come l’attacco terroristico dell’11 settembre non ci toccò più di tanto, anzi ci passò sopra e fu presto dimenticato, nel mare di lavoro e di problemi da risolvere che avevamo durante gli ultimi mesi di preparazione della missione.

L’incubo del software di bordo

Nel 2002 i test con la sonda si intensificarono. Nel frattempo, dato il ritardo nello sviluppo del software di bordo, i colleghi del progetto dell’ESTEC e quelli di Astrium proposero di spostare alcuni dei test dell’ESOC previsti sulla sonda vera e propria al modello ingegneristico. Questo ci diede più tempo per i nostri test, ma non migliorò, almeno inizialmente, la situazione difficile del software di bordo. Dopo l’ennesimo fallimento di un nostro test per via di problemi con la mission timeline, la funzione – per noi vitale – che serviva ad eseguire al tempo giusto i comandi mandati alla sonda e immagazzinati nella memoria di bordo con il tempo di esecuzione programmato per ciascun comando, nel maggio 2002 Astrium mandò all’ESOC un esperto del software di bordo, Patrick Lelong, per seguire uno dei nostri test. Fu grazie a questo nuovo tipo di cooperazione tra l’industria che sviluppava il software di bordo e lo testava a livello di sistema e noi delle operazioni, che testavamo il software usandolo come lo avremmo usato in volo, che si riuscirono a superare i problemi principali. E fu anche l’inizio di una lunga amicizia di lavoro con Patrick: imparammo a stimare e ammirare lui e il suo collega Michel Janvier non solo per la loro competenza ma soprattutto per la loro pragmatica dedizione alla risoluzione di ogni problema. Alla fine, verso l’estate del 2002, quando cominciò la nostra campagna ufficiale di simulazioni, l’Astrium era riuscita a risolvere i problemi da noi trovati e ci aveva consegnato una versione del software di bordo molto più robusta. Questo nuovo modo di lavorare e cooperare tra noi delle operazioni e l’industria che stava eseguendo gli ultimi test a livello di sistema sulla sonda è diventato da allora, grazie all’esperienza di Rosetta, il modo standard di operare per tutte le missioni scientifiche dell’ESA che seguirono.

Ciononostante la campagna di simulazioni per il lancio fu piuttosto problematica. Il nostro simulatore, un sistema software sviluppato all’ESOC per rappresentare in modo realistico il funzionamento della sonda, era in grado di utilizzare il software di bordo “installandolo” e facendolo girare su un processore emulato in software. Era una tecnica piuttosto complessa, che oggi è lo standard per tutte le missioni, ma allora muoveva i primi passi e ci aveva dato grattacapi a non finire durante la fase di sviluppo. Ma questa fatica fu ripagata durante le simulazioni, nel corso delle quali provocavamo guasti ai sistemi della sonda per addestrare il team di operazioni a reagire nel modo giusto e per verificare le procedure preparate per questi casi. Dato che il simulatore usava il vero software di bordo, queste procedure servivano anche a verificare le reazioni della sonda, codificate nel software, ai guasti simulati ai sistemi di bordo. Oltretutto durante le simulazioni i nostri colleghi responsabili dell’addestramento cercavano di stressare al massimo il team di operazioni, provocando anche più di un guasto in parallelo, cosa considerata improbabile nella realtà, ma molto utile per portare al limite e mettere alla prova in condizioni estreme le capacità dei controllori di missione.

Ma lo stress era uguale anche sul software di bordo, cosicché durante la campagna di simulazioni finimmo per trovare nuovi problemi nel software di bordo, sfuggiti alle intense campagne di test dell’industria e a quella di validazione sistematica da noi condotta nei mesi precedenti. Da una parte era bene scoprire questi problemi nel software di bordo prima del lancio, mentre la sonda era ancora a terra. D’altra parte Rosetta a quel punto era ormai completamente integrata ed era già stata trasportata alla base di lancio di Kourou, dove veniva rimontata definitivamente in attesa del lancio. Non c’era assolutamente tempo per modificare il software di bordo e immagazzinarlo in modo permanente nella sua memoria fissa. Una nuova versione che correggesse tutti i problemi da noi scoperti durante le simulazioni sarebbe stata pronta solo dopo il lancio. Chiaramente un ritardo del lancio non era nemmeno pensabile: avevamo tre settimane di “finestra” a partire dal 13 gennaio 2003, dopo di che avremmo perso il nostro appuntamento con la cometa. Per cui dovetti rassegnarmi ad accettare di lanciare una sonda che aveva a bordo vari problemi di software a noi noti, che avremmo potuto correggere solo a luglio, quando l’Astrium ci avrebbe consegnato la nuova versione “pulita” del software, mentre Rosetta sarebbe ormai stata in volo da circa sei mesi. In questo modo le correzioni sarebbero state possibili solo nella memoria riprogrammabile della sonda. In quella fissa, che Rosetta avrebbe usato solo in caso di guasti multipli che avrebbero impedito il caricamento del software riprogrammato, sarebbe rimasta la versione caricata prima del lancio, con ancora irrisolti tutti i problemi da noi trovati nel corso delle simulazioni. Insomma, non era una situazione piacevole per me e il mio team, che avevamo davanti un viaggio nello spazio profondo di oltre dieci anni. Far volare Rosetta in queste condizioni chiaramente aumentava il rischio di perdere il controllo della sonda in caso di guasti. Ma non avevamo scelta: meglio una sonda claudicante, che avremmo potuto “riparare” in volo sei mesi dopo, che perdere del tutto l’appuntamento con Wirtanen, e quindi perdere la missione prima ancora di cominciarla.