L'atterraggio di Atantis STS-135, ultima missione Shuttle, 21 luglio 2011. Davanti alla navetta, il buio pesto dei successivi programmi "manned" targati USA (NASA, Public Domain).

Causa un “incidente” web, almeno in questo spazio che è solo mio e dove perciò solo io ci scrivo, voglio un po’ esplicitare certe mie argomentazioni senza paura di essere insultato in quanto “dilettante”. Non voglio certo mettermi al livello di chi ha fatto studi specialistici: voglio solo ribadire che non c’è mai domanda abbastanza cretina da meritare una risposta maleducata. Soprattutto da chi avrebbe, a suo dire, intenzioni divulgative. Alla fine, per il semplice appassionato è meglio fare come faceva una volta: raccogliere e leggere materiale per conto suo, senza rivolgersi agli addetti ai lavori, cosa questa che una volta poteva fare solo alle conferenze nel tradizionale spazio conclusivo per le domande, e che adesso invece con il web è diventata molto più facile, ma vedo purtroppo assolutamente improduttiva.

Il mio “sassolino nella scarpa”, consiste semplicemente nell’esporre le mie riflessioni su alcuni casi di progetti aerospaziali, ma anche di altro tipo, che hanno avuto problemi, e il perché. Io non sono un tecnico, sono uno storico; quando parlo di missili, aerei e quant’altro, non sto in fondo che facendo storia, per quanto di un argomento molto particolare. Un approccio storico non può essere un approccio ingegneristico, anche se tratta della stessa materia. Non sto facendo “project management” aerospaziale.

Nella progettazione di un veicolo spaziale, ma anche di un aereo, mi sembra ci siano quattro parametri principali da considerare: 1) tempistiche 2) prestazioni 3) affidabilità / sicurezza (“safety”, detta all’americana) 4) costi (questi parametri non sono messi qui in ordine di importanza). La scelta di quali parametri siano prioritari e quali sacrificabili, è stata storicamente una scelta manageriale, al limite si potrebbe dire “politica”, non strettamente ingegneristica. Un altro parametro, che non ho messo insieme agli altri perché mi sembra più ingegneristico, è la complessità. Un buon progetto è alla fine un buon compromesso tra questi diversi parametri che sono sempre in conflitto tra loro.

Da un punto di vista storico si possono fare delle considerazioni su come le scelte di quali parametri fossero prioritari e quali no abbiano influito sulle vicende di alcuni progetti, portandoli spesso a risultati poco felici.

Enfasi sulle tempistiche

L’enfasi sulla tempistica può provocare: 1) un tentativo di riduzione della complessità oppure 2) un decadimento, spesso disastroso, dell’affidabilità / sicurezza. I casi più significativi di enfasi sulla tempistica si sono avuti durante la Guerra Fredda, in modo particolare ovviamente durante la “space race”.

Un esempio di riduzione della complessità per mantenere le tempistiche, storicamente, può essere quello del “satellite semplificato” di Korolev, cioè lo Sputnik 1. Di fronte alla prospettiva di essere battuti dagli americani durante la corsa al satellite artificiale entro la fine dell’Anno Geofisico Internazionale 1957-58, i sovietici accantonarono temporaneamente il sofisticato satellite originale, che avrebbe poi volato come Sputnik 3, e realizzarono in fretta e furia un satellite che in pratica era destinato solamente ad entrare in orbita e a dimostrare che c’era riuscito attraverso un segnale radio, il famoso “bip-bip”.

Il sacrificare l’affidabilità sull’altare delle tempistiche è stato un noto vizietto sovietico, due esempi tra tutti: 1) il primo SSBN sovietico, il K-19 della prima serie “Hotel”, la cui missione inaugurale si trasformò in tragedia quando uno dei reattori rischiò il meltdown perché, per risparmiare tempo, non era stato previsto un circuito di refrigerazione di backup (!); 2) la tragica missione di Vladimir Mikhaylovich Komarov sulla Soyuz-1 nell’aprile 1967, voluta dai vertici sovietici che avevano visto nel disastro dell’Apollo 204 / Apollo 1 del gennaio 1967 una ghiotta occasione per tornare in testa nella “space race” nella quale erano stati superati dalle missioni del programma Gemini. In vista oltretutto di un grande colpo propagandistico previsto per il cinquantenario della Rivoluzione d’Ottobre: il primo volo umano a raggiungere la Luna, anche se senza allunaggio. Eppure, tutte le missioni automatiche della Soyuz effettuate in precedenza sotto la sigla di comodo “Cosmos”, avevano avuto grossi problemi oppure erano fallite.

Anche due dei tre incidenti mortali patiti dalla NASA, segnatamente quello dell’Apollo 204 / Apollo 1 ma soprattutto quello del Challenger, dove vi furono forti pressioni per mantenere la data del 28 gennaio senza ulteriori ritardi, possono essere considerati dovuti almeno in parte a questioni di tempistiche.

Hotel II submarine
Un SSBN della classe “Hotel II”, successiva ma abbastanza simile al K-19 (US Navy, Public Domain).

Enfasi sulle prestazioni

L’enfasi sulle prestazioni ha provocato storicamente un aumento della complessità, un aumento dei costi, un allungamento delle tempistiche e, spesso, la cancellazione del progetto dopo la fase di prototipo o anche prima. Un esempio il progetto del Republic XF-103 “Thunderwarrior”, le cui specifiche tecniche sarebbero una vera sfida ancora oggi.

Republic XF-103 Thunderwarrior
Il mock-up del Republic XF-103 Thunderwarrior, caccia da mach 3 propulso da un ibrido turbo-statoreattore (USAF, Public Domain).

Enfasi sull’affidabilità / sicurezza

L’affidabilità / sicurezza è certamente il fattore principale da tenere in considerazione in un progetto, ma proprio per questo la complessità rischia di diventare un fattore cruciale. Se un progetto è troppo complesso, tende a diventare al contempo anche meno sicuro, e questo provoca in molti casi un aumento delle tempistiche dovuta alla ridondanza dei test di controllo, e questa a sua volta provoca un aumento dei costi. I progetti troppo complessi tendono così ad avere tempi di sviluppo che da biblici tendono a diventare geologici.

L’affidabilità vada di pari passo con una riduzione della complessità: più una cosa è semplice, meno probabilità ha di rompersi. Questa regola comunque va presa inserendola nel contesto in cui si trova. Quando ero bambino, ricordo che la parola più usata nel programma spaziale americano era “sofisticato”: tutto doveva essere all’assoluta avanguardia perché la NASA negli anni Sessanta aveva in fondo come scopo principale quello di dimostrare a tutto il mondo che la tecnologia americana era “the best in the world”. Di fronte alle realizzazioni sovietiche, quando erano visibili anche in occidente, la parola più usata era invece “rustico”: segno inequivocabile di due approcci ingegneristici diametralmente opposti. Eppure l’approccio “rustico”, se alla fine si è rivelato vincente – vedi il vettore Semerka e le capsule Soyuz – non ha impedito ai sovietici di avere negli anni Sessanta gravi problemi di affidabilità / sicurezza.

Quando si deve coniugare complessità (dovuta alle prestazioni) ad affidabilità / sicurezza, si viene a creare un circolo vizioso che può degenerare in quello che gli informatici chiamano “loop infinito”. Il progetto viene testato una prima volta, non viene trovato perfetto (perché la perfezione non esiste), viene modificato, si risolve il problema ma il “patch” ne crea un altro, si torna daccapo a dover cercare un nuovo “patch” che risolva i problemi del “patch” precedente, intanto i tempi di realizzazione si allungano a dismisura e con essi i costi, perché la gente che controlla e lavora sulle pezze va pagata, e avanti così. Alla fine il progetto si arena in una specie di limbo dal quale non esce perché nessun manager vuole prendersi la responsabilità del rischio di dare il “via libera” finale. Vedi la legge di Murphy: «se qualcosa può andar male, lo farà».

L’esempio più preclaro di questo loop è il James Webb Space Telescope: le caratteristiche (un pelino boriose a mio parere) del profilo di missione scelto e la necessità di far “entrare” il telescopio nel “fairing” di un Ariane 5 ha fatto del JWST un aggeggio veramente complesso dove ogni parte deve funzionare alla perfezione pena il fallimento totale. Insomma, si è costretti a un “one shoot, one kill”. Inoltre, è sempre presente l’incubo di Hubble quando, per risparmiare poche centinaia di milioni di dollari su un test allo specchio primario, la NASA fu costretta a spenderne miliardi per una missione di riparazione via Shuttle. E allo stato attuale non esiste nessun veicolo spaziale in grado di eventualmente raggiungere il JWST per ripararlo. L’incubo che qualcuno dei tanti componenti “impacchettati” non riesca a dispiegarsi alla perfezione, o peggio che l’Ariane 5 faccia un bel botto polverizzando quasi 9 miliardi di dollari, penso che non faccia dormire la notte più di qualcuno da un bel po’ di anni.

Intanto il Congresso USA brontola sempre di più sul fatto che un progetto scientifico civile viene ormai a costare al contribuente americano quanto una ben più utile (per il Congresso) portaerei nucleare. E allo stesso prezzo quanti osservatori terrestri con ottiche adattive si potevano costruire, quanti satelliti orbitali ad infrarossi ecc., si chiederà sicuramente più di qualche astrofisico? Il rischio di una cancellazione, col risultato magari che il JWST finisca a fare la polvere allo Smithsonian di Washington, è sempre presente.

JWST deployment
La lunga e pericolosa serie di “step” per la piena operatività del James Webb Space Telescope (JWST). Qualcosa di storto in uno dei passaggi, e miliardi di dollari andranno in fumo (NASA, Public Domain).

Alla fine, quello che conta è sempre il rapporto costi/benefici che è sempre visto soprattutto da un punto di vista economico-politico e solo in seconda battuta di ricerca scientifica e tecnologica in sé. A questo punto ci sta bene un istogramma che ho trovato sul blog di Christopher R. Cooper, sperando che l’autore mi conceda il “fair use”:

Spese federali USA
No comment (Christopher R. Cooper, fair use).

Il JWST, che è un programma “unmanned”, sta facendo vedere come la vecchia polemica sul costo dei programmi spaziali sta trascendendo la vecchia contrapposizione alla James Van Allen tra programmi spaziali con equipaggio e programmi spaziali automatici. Proprio questo tema può introdurre un altro esempio di allungamento dei tempi di sviluppo, quello che è all’origine del sassolino nella scarpa di cui al titolo: le capsule “private” americane.

Dopo il tragico disastro dello OV-102, il vero motto dell’astronautica americana sembra essere diventato “mai più un altro Columbia”. Nel 2003, si decise di puntare sulle capsule a scapito degli aerospazioplani. La motivazione era plausibile: le capsule sono più semplici, sicure e collaudate: in fondo, vanno in orbita dal 1961, la loro aerodinamica e il loro profilo di missione sono ben conosciuti, la loro struttura costruttiva è collaudata, soprattutto per quanto riguarda la protezione termica, ecc. Si facevano paragoni impietosi, ancorché malposti, tra lo Space Shuttle e le capsule Soyuz. Progettare una capsula, costruirla e farla volare nel giro di pochi anni sarebbe stato un gioco da ragazzi per una grande industria privata rispetto alla elefantiaca, farraginosa e pubblica NASA, dinosauro degli anni Sessanta. Eppure, anche le grandi firme aeronautiche e i miliardari rampanti, nonostante gli indubbi successi (sempre “unmanned” però…), quando si è trattato di fare il salto della capsula con equipaggio, hanno iniziato ad avere problemi e a posporre in continuazione il fatidico primo lancio.

Tecnologie vecchie e nuove

Non è il mio mestiere per cui non lo dico con cognizione di causa, ma penso che il genio di un ingegnere stia nell’usare la tecnologia giusta al posto giusto, anche quando questa può sembrare a prima vista obsoleta. Non c’è dubbio che la tecnologia più recente dia in genere migliori prestazioni, ma questa non è una legge metafisica. Qualche anno fa, fu proposto per l’esplorazione di Venere un rover, che, date le ben note condizioni di temperatura e pressione alla superficie del pianeta che friggerebbero in poco tempo qualsiasi circuito integrato, era in pratica una via di mezzo tra un carro armato britannico della Prima Guerra Mondiale e un computer analogico che ricordava più i robot degli orologiai del Settecento piuttosto che le tecnologie digitali attuali. Il nome era AREE, che stava per “Automaton Rover for Extreme Environments”.

AREE (Automaton Rover for Extreme Environments), il rover analogico per l’esplorazione di Venere (NASA, Public Domain).

Inoltre, è inutile negarlo, viviamo in una perenne “crisi del software”. Qualsiasi lettore di RID o JP4 sa che il JSF ha volato per la prima volta come X-35 nel 2000, come F-35 nel 2006, e che i primi esemplari hanno raggiunto la IOC tra il 2015 e il 2019 a seconda delle versioni. E per la capacità operativa “full” quanto ancora ci occorrerà? Nel frattempo l’F-35 è diventato il più costoso programma aeronautico militare della storia. Ma se vola già da praticamente vent’anni, perché? Per i “Blocks” del software di missione… Io conosco molti appassionati di aviazione coi quali, essendo al mio livello, non ho problemi di “interfaccia”, e mi sembra a volte che per diversi di loro l’F-35 sia più che altre cose un atto di fede nei confronti del mondo occidentale. Però molti di questi miei amici alla fine sono costretti a darmi ragione quando, di fronte alle continue “guerre asimmetriche”, dico che per il Pentagono la cosa migliore sarebbe riaprire la linea di produzione del Douglas A-1 Skyraider.

Un Douglas A-1J Skyraider dell’USS Intrepid, Vietnam 1966 (US Navy, Public Domain)-

Il software è solo uno strumento, e uno strumento infido. Qualsiasi software, più diventa complesso più diventa ingestibile, perché inizia a soffrire di queste malattie croniche: 1) progetti oltre il budget; 2) progetti oltre i limiti di tempo; 3) software di scarsa qualità; 4) software che spesso non rispetta i requisiti; 5) progetti ingestibili e software difficile da manutenere. Di fronte ad una maggiore complessità del software, la sua usabilità ha un andamento simile ad una gaussiana: oltre un certo punto ottimale, il software più complesso non risolve più problemi, invece ne crea.

Post Scriptum. Un buon progetto aerospaziale dovrebbe avere tra le sue doti anche un buon quantitativo di quella che gli psicologi chiamano “resilienza”, ossia una sua capacità intrinseca di sopravvivere ai guasti. Il 10 gennaio 1964 un Boeing B-52 riuscì ad atterrare in emergenza senza il timone verticale di coda, un incidente che avrebbe fatto precipitare la stragrande maggioranza degli aerei. Poi ci si chiede il perché sia ancora in servizio.

tailless B-52
Il B-52 “senza coda”. La foto non ha bisogno di commenti (USAF, Public Domain).

 

https://www.repubblica.it/economia/diritti-e-consumi/trasporti/2018/01/02/news/anno_record_per_la_sicurezza_in_aereo_un_incidente_ogni_7_36_milioni_di_voli-185661705/
http://www.spacepolitics.com/2006/08/10/james-van-allen-and-the-human-spaceflight-adventure/
https://en.wikipedia.org/wiki/List_of_Soyuz_missions
http://www.eyewitnesstohistory.com/b17.html
https://christopherrcooper.com/blog/apollo-program-cost-return-investment/?fbclid=IwAR1iMjCA8QeQ2TH1CHGTzGPPNdSnS0evbmUZe__x-AoMkMg92nWtNcKWzBY
https://www.nasa.gov/feature/jpl/a-clockwork-rover-for-venus
https://www.smashingmagazine.com/2014/06/user-total-control-designers-nightmare/