Con il consueto stile del diario di viaggio, il resoconto sull‘esperienza di robotica spaziale in Giappone affronta in questo articolo i problemi architetturali e tecnologici in maniera più approfondita. Si iniziano a delineare con precisione i problemi connessi con il funzionamento del rover El Dorado e a ipotizzare le soluzioni tecnologiche che andranno implementate.

Un mondo nuovo

Passai i primi dieci giorni del mio soggiorno giapponese ad adeguarmi alle novità. A volte sentivo il peso di non poter vedere le mie figlie così a lungo. Non avendo Internet a casa, potevo chiamarle solamente nel tardo pomeriggio dall’ufficio, nel momento in cui un Italia iniziava la mattinata. Sentivo fortissima la mancanza di Emi e Ike, i mie adorati cani, che avevo dovuto lasciare in Italia alle cure fidate di mio fratello. Non disponendo di un tavolo e una sedia, finii per passare ben poco tempo nel mio “appartamento”, se si fa eccezione per la notte. Questa riduzione degli spazi di intimità mi fece provare, in principio, un senso di alienazione pazzesco, data la difficoltà a trovare qualcosa di familiare a cui fare riferimento nel mondo che mi circondava.

Un nuovo senso di libertà

Poi, con grande sorpresa, scoprii un incredibile senso di libertà e di autosufficienza. Dopo una settimana trascorsa a dormire nel mio appartamento da dieci metri quadri, mi resi conto che, davvero, non avevo bisogno di niente di più. Le mie esigenze di spazio si erano fatte prossime allo zero. Il mio guardaroba estivo consisteva in un paio di jeans, due di shorts, 12 magliette, una felpa, una giacca e biancheria per dieci giorni. Al termine dei dieci giorni, andavo al piano terra dell’edificio a fare un bucato nella lavanderia a gettoni, quindi ero pronto a riprendere da capo. Senza mobili, e lasciando le scarpe all’ingresso, le esigenze di manutenzione si ridussero al minimo. Quanto credete ci voglia a tirare su la polvere da un parquet di 10 metri quadrati? Più o meno 4 minuti. Il mini-bagno della Yamaha? Anche volendo fare le cose per bene, non non riuscivo a metterci più di un quarto d’ora alla settimana.

In università avevo fatto amicizia con i ragazzi del laboratorio, e di fatto trascorrevo la maggior parte del mio tempo in loro compagnia. Fuori dal laboratorio, imparai ad apprezzare il fatto di poter girare liberamente senza essere riconosciuto da nessuno. Questa sensazione di anonimato mi aprì nuovi orizzonti: mi resi conto infatti che all’occorrenza potevo trasformare qualunque luogo pubblico in uno spazio intimo, in cui rilassarmi e riconnettermi con me stesso. Subito fuori di casa avevo un piccolo convenient store della Seven-Eleven, aperto 24 ore su 24. Le città giapponesi sono piene di piccoli minimarket di questo tipo, dove è possibile trovare alimentari, prodotti per la pulizia e l’igiene, biancheria e qualunque altro prodotto necessario alla sussistenza. Nel raggio di 500 metri avevo ristoranti, take-away, l’ufficio postale, due fermate dell’autobus e una del treno. C’erano anche due parchi pubblici piuttosto grandi, illuminati alla sera. Il centro di Sendai era a meno di dieci minuti in autobus, o mezz’ora a piedi. Comprai una bicicletta e cominciai a muovermi liberamente: presi confidenza con i dintorni, e a poco a poco l’intera città di Sendai divenne un’estensione del mio appartamento, un appartamento da 730 chilometri quadrati, con una camera da letto da 10 metri quadri.

Senza telefono

L’assenza del telefono cellulare fu un’altra liberazione. Siamo così abituati alla loro presenza che fatichiamo a capire quanto poco ci servano in realtà. Non ci credete? Provate a spegnere il telefono per una settimana. No, sul serio, provate a farlo. Meglio ancora: chiedete a qualcuno di nasconderlo, in modo da non averlo nemmeno per casa. Dopo un paio di giorni con le palpitazioni, scoprirete con sorpresa che il mondo continua ad andare avanti esattamente come prima. Padroni del vostro tempo, scoprirete un incredibile livello di produttività esente da distrazioni. E cosa succede se qualcuno vi cerca con urgenza? Tranquilli, lo verrete a sapere comunque, quando sarete nel tempo e luogo migliori per rispondere. Pensateci bene: quante volte nell’ultimo anno avete ricevuto una chiamata realmente urgente, una di quelle che possono fare la differenza tra la vita e la morte? La verità è che in caso autentica emergenza, le opportunità per risolvere la situazione si trovano nelle immediate vicinanze, normalmente a meno di 300 metri di distanza. Il mito della necessità della reperibilità continua è proprio questo: un mito. Ripresi l’abitudine a pianificare gli appuntamenti, a dare valore ad ogni chiamata, a incontrare le persone in luoghi e orari precisi, invece di vivere in uno stato di perenne transizione, scandito dalla frase “ci risentiamo dopo”.

Una cena di benvenuto

In Giappone il rapporto con la cucina è simile a quello che abbiamo in Italia. Il cibo è considerato sacro, una sorgente di vita, e questa alta considerazione può essere percepita nel modo in cui il cibo viene presentato.

La presentazione è sempre impeccabile anche in catene di ristorazione economiche, o nei cibi preconfezionati che vengono venduti al supermercato. Molti ristoranti presentano un menu illustrato, che semplifica la scelta a noi stranieri. Le foto non sono molto utilizzate nei ristoranti tradizionali, dove il menu è scritto solamente in giapponese: in questi casi, basta chiedere un suggerimento allo chef, sicuri di ricevere una piacevole sorpresa.

Ristoranti e socialità

In Giappone, dove lo spazio abitativo è estremamente prezioso, il cibo viene spesso consumato al ristorante. I ristoranti sono organizzati in salette, che vengono prenotate per la serata da gruppi di persone. Pareti divisorie mobili permettono di accomodare gruppi di diverse dimensioni. Il Giappone è un Paese che non incoraggia l’individualismo: fin da piccoli, i Giapponesi imparano a identificare se stessi in base ai gruppi a cui appartengono, siano essi la famiglia, la scuola, il clan o l’azienda. Questo senso di appartenenza viene coltivato in diverse maniere: una di queste sono le cene sociali. Le aziende organizzano con cadenza mensile delle cene dove vengono serviti cibo e bevande alcoliche in abbondanza. Gli orientali hanno per costituzione una carenza di ALDH2, gli enzimi che metabolizzano l’alcool, e per questo tendono a ubriacarsi in fretta. Pertanto le serate aziendali terminano generalmente in una gran baldoria di canti, abbracci risate e mal di testa. In Giappone l’ubriachezza non è stigmatizzata come da noi: se uno pubblica su Facebook foto di colleghi di lavoro ubriachi, ad esempio, la cosa può divertirli o lasciarli indifferenti, ma difficilmente li farà arrabbiare. Nella cultura Giapponese, un uomo adulto che lavora ha il diritto a ubriacarsi il sabato sera, a cantare e a ballare al ristorante e a tornare a casa barcollando. Una cosa che da noi potrebbe causare grossi imbarazzi, in Giappone è considerata un segno di serietà, una testimonianza di dedizione al lavoro.

Durante le cene, il cibo viene servito per tutto il corso della serata in piccole porzioni su piatti dai mille colori. I piattini di servizio vengono messi in centro al tavolo: se il cibo lo permette, è consentito mangiare direttamente dal piatto comune usando le bacchette.

Con un po’ di pratica, le bacchette diventano un’estensione della mano, e diventa sempre più facile utilizzarle. Il cibo è preparato in porzioni comode da “pizzicare” e da introdurre in bocca. Alcune pietanze, come ad esempio il riso, hanno una grana troppo sottile per essere maneggiate agevolmente con le bacchette: in questi casi, il galateo impone di avvicinare il piatto alla bocca e di usare le bacchette per spingere il cibo tra i denti.

Tra le pietanze che vengono comunemente servite in una serata non manca mai il pesce, spesso crudo e in forma di sashimi. La presentazione del sashimi è sempre spettacolare, guarnita da verdure colorate su piatti decorati.

Il brindisi d’onore

A metà serata, l’ospite si alza per fare gli onori di casa, e incoraggiare un brindisi. In questa particolare serata, i festeggiati eravamo io e i miei amici Remi, Roxanne, David e Asif, dato che ci eravamo appena aggregati alla famiglia del laboratorio di robotica.

Il professor Yoshida invitò i ragazzi del laboratorio a presentarsi a noi: a uno a uno, i ragazzi del laboratorio si alzarono per fare le presentazioni. Con grande calore e cortesia, i ragazzi si presentarono con un breve discorso, rigorosamente in giapponese. Come avevo già avuto modo di notare, la lingua inglese non era il loro forte, e tutti noi apprezzammo comunque il gesto. Quando arrivò il mio turno, decisi comunque di “vendicarmi”, e di presentarmi parlando in Italiano: “Sono molto lieto di essere qui con voi questa sera, e mi auguro di passare una meravigliosa estate con tutti voi. Vi saluto con l’unica parola di Giapponese che conosco: Arigato!”. Il mio discorso venne accolto da un’ovazione: curiosamente, a fine serata era l’unico che tutti ricordassero.

L’analisi del software di controllo di El Dorado

Ma non ero in Giappone solo per assaporare le piacevoli tradizioni gastronomiche di questa antica e raffinata cultura. C’era un rover da far funzionare al meglio e, in definitiva, il tempo a disposizione per concludere questa missione non era moltissimo.

Nel corso della prima settimana, portai a termine la mia valutazione dell’architettura di El Dorado. La totale assenza di documentazione mi costrinse a ricostruire l’architettura a ritroso, navigando il codice sorgente. Lo studio del sistema mi sollevò diverse perplessità, legate alla precarietà dell’architettura. Scrissi le mie conclusioni in uno status report, e preparai una presentazione per Yoshida, il direttore del laboratorio e Keiji Nagatani, professore associato responsabile dei rover planetari.

Il sistema

Il sistema era estremamente precario. Il computer del rover era basato su scheda madre ITX dotata di un processore Pentium IV. I motori e i sensori erano collegati internamente attraverso porte USB. Il sistema operativo era una distribuzione ridotta di Linux, che presentava dei comportamenti idiosincratici, come l’impossibilità di creare socket di tipo server aperte verso l’esterno, dovuta forse a una errata configurazione dei filtri IP.

La scelta di Linux era giustificata principalmente da ragioni sentimentali e “ideologiche”, come l’idea che quella fosse la soluzione più adatta alla circostanza, data la disponibilità del codice sorgente, il ridotto consumo di risorse e le prestazioni. Il problema era che in tutto il laboratorio non c’era una singola persona che avesse le competenze necessarie ad amministrare e riparare la configurazione del sistema operativo e questo rendeva El Dorado una terrificante black box che nessuno aveva il coraggio di toccare.

Linux è un sistema straordinario che presenta numerosi vantaggi: ridotto consumo di risorse, modularità, presenza del codice sorgente, possibilità di controllare il sistema attraverso la riga di comando… Il fatto è che l’amministrazione di Linux richiede delle competenze precise, in assenza delle quali si ottengono delle installazioni subottimali. Se uno non sa amministrare il sistema, il fatto di avere o meno i sorgenti cambia poco le cose. Capita spesso di parlare con persone che dipingono le meraviglie di Linux, ma che poi di fatto utilizzano Windows sul loro computer. Io penso che se qualcosa non ti piace, dovresti fare a meno di usarla: in caso contrario puoi trovarti in situazioni schizofreniche che finiscono per produrre seri problemi.

Di fatto, il sistema ospite aveva abbastanza risorse da permettere una distribuzione minimale di Windows, una scelta che avrebbe offerto un livello di controllo molto maggiore ai ragazzi del laboratorio. I requisiti real time non erano particolarmente stringenti – nell’ordine della decina di millisecondi – per cui non c’erano ragioni prestazionali a forzare la scelta. Motori e sensori erano collegati via USB, e pertanto sarebbe stato possibile scrivere il software di controllo al di sopra di qualunque sistema operativo, perfino Mac OS X, il sistema operativo più chiuso del mondo.

Una riparazione a livello di sistema operativo era ovviamente fuori discussione. Il software di controllo era stato sviluppato e compilato direttamente sul rover in diversi momenti da diversi individui, e non esisteva alcuna documentazione che permettesse di ricreare la configurazione. La macchina e la sua configurazione software erano un tutt’uno che non era possibile modificare senza il rischio di compromettere l’instabile equilibrio e costringere a ricominciare tutto daccapo. L’uso superficiale di Linux, senza disporre delle necessarie competenze, porta spesso a installazioni di cui si finisce per perdere il controllo. In casi come questo, le cose funzionano fino a quando non funzionano più. E quando le cose non funzionano più, il recupero diventa difficile e costoso, o addirittura impossibile.

L’architettura

Il sistema era composto da sette componenti, cinque residenti nel rover e due nella macchina client. La macchina client era un PC Windows, dotato di un Joypad USB da X-Box. Una volta avviato il sistema, era possibile comandare il rover attraverso il joypad e controllare a schermo lo stato della mappa digitale di rilievo. Curiosamente la parte di navigazione e quella di controllo erano gestite da due sistemi distinti e non integrati tra loro. Navigando il codice sorgente era possibile farsi un’idea del livello di esperienza degli autori dei vari componenti, almeno per quel che riguardava il software, visto che a livello di ingegneria meccanica e aerospaziale c’era ben poco da eccepire.

• System, ossia il software di controllo della macchina. System comprendeva uno strato di primitive di basso livello, che permettevano di comandare in maniera indipendente qualunque motore della macchina, e due livelli di astrazione superiori, che permettevano di controllare la macchina con comandi del tipo “ruota a destra di 20 gradi” o “vai avanti per 10 metri”. System era basato su un ciclo che ogni 50 millisecondi leggeva da un segmento di memoria condivisa il comando da eseguire. A quel punto, modificava lo stato della macchina, attivando o disattivando i motori corrispondenti, quindi leggeva il valore dei sensori, lo scriveva sulla memoria condivisa e andava in sleep per altri 50 millisecondi.
• Shared Memory, una sorta di bus software che permetteva a System di dialogare con altri componenti che necessitavano di modificare lo stato della macchina. L’accesso alla memoria condivisa avveniva attraverso un’interfaccia di programmazione composta da una cinquantina di funzioni. System era una risorsa condivisa regolata da un meccanismo di sincronizzazione basato su locking di variabili di stato, corrispondente a una classe Java con metodi synchronized . Purtroppo il meccanismo di locking non utilizzava direttive di sincronizzazione del sistema operativo, e pertanto non era thread-safe.
• Urg3Dnew_DemViewer era il modulo che controllava l’altimetro laser, effettuava una scansione dell’ambiente ogni 3 secondi, generava la mappa digitale di rilievo (DEM – Digital Elevation Map) e la salvava su un file di testo. Il software conteneva sia la parte di controllo dell’hardware che la logica di generazione della mappa.
• RemoteServerDEM si attivava ogni 4 secondi, leggeva il file di testo contenente la descrizione della mappa digitale di rilievo e la inviava al software client attraverso una connessione TCP/IP. La scelta di un intervallo di polling di 4 serviva a ridurre la probabilità di leggere il file nel momento in cui questo veniva scritto da Urg3Dnew_DemView. Questo primitivo meccanismo di sincronizzazione tendeva a fallire di quando in quando; l’autore aveva introdotto a tal fine file una somma di controllo, che permetteva al programma ricevente di riconoscere quando il file era in uno stato inconsistente e, pertanto, di scartare il file. Leggendo il codice, avevo il sospetto che l’autore non avesse realizzato la vera natura del problema, e che attribuisse l’occasionale presenza di errori a problemi di comunicazione.
• DoraViewer era il componente che eseguiva la visualizzazione a schermo della mappa digitale di rilievo. DoraViewer apriva una connessione TCP con RemoteServerDEM, riceveva la descrizione della mappa digitale di rilievo e la presentava a schermo in grafica tridimensionale. Il programma aveva un’interfaccia grafica molto primitiva che non offriva un grosso livello di interattività.
• RemoteServer apriva una socket UDP/IP e restava in attesa di direttive di controllo. Quando queste arrivavano, generava i comandi di controllo corrispondenti e li scriveva sulla memoria condivisa. I comandi non venivano accodati: solo l’ultimo comando veniva eseguito, dato che in caso contrario il programma avrebbe finito per bufferizzare i comandi e perdere la capacità di reagire in tempo reale. Il programma poi andava in sleep per 120 ms, per dare tempo a System di leggere il comando ed eseguirlo.
• JavaJoy era il componente che leggeva lo stato di un Joypad USB ogni 100 ms, creava una direttiva di controllo e la inviava via UDP a RemoteServerDEM. La direttiva di controllo non presentava un adeguato livello di astrazione: il pacchetto infatti era costituito da una serie di numeri che venivano trascritti, sul lato server, nella memoria condivisa, dove venivano trasformati in direttive di movimento.  Anche in questo caso, la sincronizzazione tra programma client e server dipendeva dal fatto che il ciclo di invio usava un intervallo differente da quello di ricezione. Di fatto, questo meccanismo rendeva il sistema di controllo estremamente inaffidabile: a volte trascorreva anche un secondo prima che un comando del joystick venisse recepito dal rover ed eseguito.

La diagnosi

Il sistema soffriva di gravi problemi di integrazione. L’avvio del sistema richiedeva una procedura estremamente complessa, che durava circa 20 minuti. Ogni componente andava avviato in remoto, utilizzando una shell SSH separata. Alcuni componenti richiedevano il lancio di due shell, dato che il setup dei processi non era stato automatizzato.

Il software era formalmente scritto in C++, ma di fatto era stato scritto in uno stile inconsistente, che utilizzava alcuni costrutti C++ in un contesto di programmazione procedurale. Il software client era stato scritto in C++ per Linux, ma veniva fatto girare sotto Cygwin, un ambiente di esecuzione Posix per Windows che permette di compilare ed eseguire sotto Windows programmi scritti per Linux. Di fatto, il programma non era mai stato compilato ed eseguito sotto Linux, e conteneva alcune dipendenze da Cygwin che ne impedivano la portabilità. La scelta di Cygwin era dovuta al fatto che i ragazzi del laboratorio erano abituati a lavorare al software di controllo del rover in C++ sotto Linux, e che non avevano esperienza sufficiente a tentare un approccio differente per la programmazione client. Il risultato era subottimale sul piano delle prestazioni, instabile sul piano dell’architettura e scarsamente utilizzabile sul piano dell’interfaccia utente.

I componenti non erano stati fattorizzati in maniera efficiente. Per fare un esempio, System era – in teoria – il componente responsabile di interfacciare il sistema con l’hardware. Di fatto, Urg3Dnew_DemViewer aveva libero accesso all’hardware, e controllava direttamente l’altimetro laser. I meccanismi di comunicazione tra moduli erano inconsistenti tra di loro e instabili dal punto di vista della sincronizzazione: la comunicazione tra i vari componenti avveniva via TCP, UDP, memoria condivisa e accesso concorrente ad un file di testo.  Ogni componente presentava una serie di dipendenze non documentate, che rendevano impossibile replicare l’ambiente di esecuzione.

Integrare tutto in un’unica visione

L’assenza di documentazione era aggravata da una scelta estremamente infelice dei nomi di variabili, funzioni, files nonche’ dei componenti stessi. Il componente System aveva un nome troppo generico, che era facile fraintendere. Il nome Shared Memory, invece, era inappropriato per il fatto che confondeva lo scopo del componente con i mezzi usati per realizzare tale scopo. Lo scopo del componente era permettere la comunicazione tra diversi processi; il mezzo utilizzato era la Shared Memory. Nella letteratura informatica, Shared Memory denota un preciso meccanismo di comunicazione tra processi usato da UNIX e altri sistemi operativi, meccanismo che è stato utilizzato in questo caso. Può sembrare un capriccio semantico, ma dovremmo sempre trattenerci dall’utilizzare il nome di una categoria per denotare una specifica istanza, per la stessa ragione per cui non chiameremmo mai il nostro cane “Cane”. Infine, un nome come Urg3Dnew_DemView desta un milione di perplessità. “Urg”, “3D” e “DEM” son acronimi che possono avere decine di interpretazioni, nessuna delle quali può essere data per scontata (secondo Acronym Finder, il solo DEM ha 148 possibili interpretazioni). Il componente viene definito “new”, “nuovo”, senza che sia chiaro “rispetto a cosa”. Non è corretto su quello che è lo scopo del componente, che viene definito “DemView”, quando piuttosto è un “DemGenerator”. Nomi come questi causano grandissima confusione, e rendono l’architettura poco chiara e, in ultima istanza, instabile. Per questa ragione, non dovrebbero essere usati mai.

Quello che mancava, in definitiva, era una visione di insieme. La visione è ciò che fa la differenza tra un Sistema e una collezione di programmi. La mia raccomandazione fu pertanto quello di scartare interamente il software lato client e corrispondenti componenti lato server, e riscrivere il software di navigazione e controllo seguendo una architettura stabile e consistente, e costruire le nuove funzionalità in cima alla nuova architettura.

Presentare la soluzione

Mi presentai di fronte a Yoshida e Keiji con la mia analisi. Uno ad uno, illustrai i punti della mia valutazione, e proposi la mia soluzione. La mia presentazione venne accolta con scarso entusiasmo: “Non so,” disse Yoshida,”il software fa già queste cose… A noi serve solo la navigazione target based…”. “Immagino che tu abbia esperienza… Ma cosa succede se non riesci a completare il sistema in tempo? Finiremmo per trovarci un pezzo di software incompleto, che i miei studenti non saprebbero rielaborare,” fu il commento di Keiji. Io li rassicurai sulla mia proposta, e promisi di consegnare il prodotto finito entro il termine dello stage.

Rimasi molto perplesso della loro reazione, e mi ci volle quasi un mese per capirne la ragione. Il Giappone è un Paese che vive una apparente contraddizione: curioso verso la novità da un lato, sospettoso verso il cambiamento dall’altra. La novità, in altre parole, viene accolta con favore solamente quando non mette in discussione lo status quo. Il Giappone ha una grossa inerzia verso il cambiamento, che viene vissuto come una sorta di fallimento, una sorta di tacita ammissione che il modo in cui sono state fatte le cose fino ad ora era sbagliato. Il cambiamento viene visto anche come una mancanza di rispetto verso chi ci ha preceduti.

Questa tendenza può essere vista anche nel campo delle tecnologie. Il Giappone è stato uno dei primi Paesi al mondo a introdurre gli smartphone e la trasmissione dati su rete cellulare 3G. Questa adozione precoce rispondeva alla necessità di permettere agli utenti di scrivere mail con scrittura ideografica, una cosa che sarebbe stata difficile da gestire con reti di generazione precedenti. Da allora le cose sono rimaste pressoche’ invariate, e i cellulari giapponesi sono stati via via superati dagli smartphone Apple e Android. L’abitudine a fruire Internet su cellulare ha di fatto soffocato lo sviluppo della una cultura del Wi-Fi che è fiorita da noi. In Giappone è praticamente impossibile trovare locali con accesso alla connessione Wi-Fi. Persino gli alberghi che offrono accesso Internet lo fanno in attraverso reti cablate, e le università non dispongono di reti wireless dipartimentali.

Conclusioni

Insomma, nel criticare il sistema preesistente, avevo mostrato una indelicatezza difficile da accettare nel Paese del Sol Levante. Di fatto, le mie osservazioni non volevano essere una critica al lavoro svolto dai ragazzi che mi avevano preceduto. Nelle settimane successive ebbi modo di fare amicizia con gli autori dei vari componenti: erano ottimi ingegneri meccanici, ed era assolutamente normale che non avessero grossa esperienza nel software design, così come io non ho alcuna esperienza di meccanica. Parlando con loro ebbi modo di comprendere il loro mondo, le loro priorità, le loro esigenze, e a progettare la mia soluzione in modo da andare loro incontro. E poco prima della fine del mio soggiorno, avrei trovato il modo di fare un tributo al loro lavoro al momento della consegna del mio sistema.

Tra socialità al ristorante, e involontari “affronti” all’innato conservatorismo giapponese, anche per questo mese abbiamo terminato. Nel prossimo articolo andremo a vedere i dettagli dell’architettura che ho sviluppato, e cominceremo a discutere alcuni dettagli implementativi.

Andrea Gini

Andrea Gini è un professionista del settore aerospaziale, un consulente IT e un giornalista scientifico. La collaborazione con MokaByte, iniziata nel lontano 1999, è stata l‘unica costante in un percorso professionale che lo ha portato dalla fotografia professionale alla scienza spaziale. Attualmente lavora al Payload Safety Review Panel presso il centro di sviluppo tecnologico ESTEC dell‘Agenzia Spaziale Europea (ESA) a Noordwijk, nei Paesi Bassi. Andrea è anche fondatore ed editore responsabile dello Space Safety Magazine, un giornale specializzato pubblicato congiuntamente dall‘International Association for Advancement in Space Safety (IAASS) e dalla International Space Safety Foundation (ISSF). Nella IAASS, Andrea ricopre il ruolo di Chairman dell‘Information and Communication Committee, ed è responsabile dello sviluppo della strategia di comunicazione dell‘associazione. Nel tempo libero, ama stare con le figlie, cucinare, viaggiare, suonare con la chitarra, studiare le lingue e la storia contemporanea, abbracciare il suo cane e ascoltare la musica degli Who, dei Led Zeppelin, di Rihanna, 50 Cents, Eminem, Lady Gaga e Britney Spears.