I computer della NASA : il Progetto Shuttle. Contrariamente ai progetti Gemini ed Apollo, la NASA desiderava un computer completo per lo Shuttle . Memoria, circuiti integrati, sistemi.
di Luigi Morelli
Space Shuttle, la “navetta spaziale” ideata tenendo a mente i criteri di economicità e riusabilità tanto cari alla NASA. L’idea di un orbiter riutilizzabile non era in effetti nuova: già alcuni progetti tedeschi datati intorno alla fine della Seconda Guerra Mondiale mostrano un veicolo portato in quota da un bombardiere che parte con propulsione a razzo e torna alla base dopo aver compiuto il proprio compito. Ciò che la navetta tedesca non prevedeva era invece il sistema integrato e ridondante di computer di cui lo Shuttle venne dotato.
Oggi la navetta spaziale fa bella mostra di sé e crea una tessera di notevole importanza nella storia della conquista dello spazio e nell’immaginario collettivo: numerosi film di fantascienza attuali ne prevedono la presenza, da “Armageddon” a “Space vampires”, da “The Astronaut’s wife” al visionario “2001: a space odissey”, sino a “Space cowboys”. In quest’ultimo, in particolare, vengono mostrate sequenze interessanti in cui si parla dell’avionica dello Shuttle, mutuata da quella di B52 e di F16, e della caratteristica di richiedere un allenamento per lancio e permanenza nello spazio drasticamente minore rispetto al Progetto Apollo: si avvicina in sostanza l’epoca in cui lo Shuttle verrà utilizzato come mezzo di trasporto orbitale alla stessa stregua di un normale aviogetto di linea, o quasi.
Evoluzione del sistema di computer dello Shuttle
La ricerca per il progetto STS iniziò nei tardi Anni Sessanta, prima che il primo uomo scendesse sulla Luna. La NASA cercava uno strumento in cui i componenti costosi (motori, razzi a propellente solido e l’orbiter) potessero essere riutilizzati, mentre il componente sacrificabile era rappresentato dal serbatoio esterno di carburante. L’orbiter avrebbe dovuto planare durante il rientro senza l’ausilio di motori. Allo stesso modo il sistema di computer subì diverse modifiche, e venne alla fine affidato al team Rockwell/IBM, con parte dei tecnici al lavoro dotati dell’esperienza acquisita durante le missioni Gemini ed Apollo.
Esistevano due aspetti del problema di progettazione del computer: quello funzionale e quello dei componenti. I progetti precedenti utilizzavano il computer esclusivamente per guida, navigazione e controllo di assetto, ma numerosi fattori nella progettazione dell’astronave portarono a crescere il numero delle funzioni richieste. Gli studi effettuati suggerivano tre differenti approcci alla risoluzione del problema: il primo assegnava un piccolo computer specializzato a ciascuna funzione, distribuendo i processi in modo che il malfunzionamento di un solo computer non mettesse in pericolo gli altri sistemi di controllo della nave; il secondo proponeva un computer centralizzato con capacità di time-sharing, estendendo i concetti già sperimentati per Gemini ed Apollo. L’ultima variante prevedeva diversi processori utilizzanti una memoria comune, praticamente la fusione delle due idee precedenti. Inutile sottolineare che nel 1971 erano già stati vagliati quattro sistemi multiprocessore per quest’ultima variante.
Per quanto riguardava la capacità elaborativa, si valutò di progettare un sistema con un processore almeno del 50% – 100% più potente rispetto alle esigenze attuali, consci della crescita esponenziale avuta dai progetti precedenti nello sviluppo del software. Una ulteriore modifica rispetto ai progetti precedenti imponeva l’utilizzo di aritmetica floating-point. I computer precedenti infatti adottavano una aritmetica a virgola fissa, per cui lo scaling dei calcoli doveva essere scritta nel software, ed era stato appurato che i computer di Apollo avevano richiesto almeno il 30% del tempo di sviluppo di tutto il software solo per eseguire le conversioni necessarie.
Rimaneva un ulteriore componente da valutare: la memoria.
Ridondanza
Oramai rimpiazzata da memorie a semiconduttore su circuiti integrati, la memoria a nuclei di ferrite rappresentava ancora il “non plus ultra” nelle applicazioni militari ed aeronautiche a causa del tempo di caricamento nullo dei programmi. In più iniziò a farsi luce negli ambienti di progettazione il concetto di bus, per lo spostamento di grandi quantità di dati su apparecchi militari sempre più dipendenti dall’elettronica. In aggiunta occorre ricordare che, dal momento che la ridondanza era una delle parole chiave del progetto, era necessario consentire a più computer presenti sulla navetta di “parlare” tra loro, consentendo in questa maniera un sistema di votazione il più rapido ed efficiente possibile. I primi studi per lo Shuttle prevedevano il concetto di “fail operational/fail operational/fail safe”: un problema e la missione poteva continuare, due problemi e la missione doveva considerarsi abortita, dal momento che un eventuale terzo problema avrebbe ridotto la ridondanza a sole tre macchine, il minimo necessario per la procedura di votazione. In un progetto del 1970 un computer special-purpose gestiva le funzioni di controllo di volo (il “fly-by-wire”) mentre un altro computer general-purpose si occupava di guida, navigazione e funzioni di gestione dei dati. Questi due computer avevano gemelli e l’intero gruppo di quattro era duplicato per offrire il sistema di ridondanza richiesto.
Nel 1971 vennero proposti due nuovi progetti: uno più economico, l’altro più ambizioso. Il primo utilizzava due gruppi di AGC (Automatic Guidance Control) contenenti 32K di memoria cancellabile e memoria di massa su nastro magnetico anziché le “core ropes” dell’Apollo, mentre l’altro, ambizioso, proponeva un sistema di computer “collaborativi” che offrivano “scarsa potenza elaborativa individuale”. Il cuore del sistema era composto da un sistema multiprocessing relativamente ampio con processori locali a livello di sottosistema per isolare il computer centrale dalle eventuali modifiche dei sottosistemi.
Il sistema definitivo
Contrariamente ai progetti Gemini ed Apollo, la NASA desiderava un computer completo per lo Shuttle. Cinque sistemi con qualifica “space” superiore alle specifiche militari erano a quel tempo disponibili: l’IBM 4Pi, l’Autonetics D232, l’Alpha della Control Data Corporation, il Raytheon RAC-251 e l’Honeywell HDC-701. Il profilo minimo per i sistemi computerizzati si era evoluto includendo lunghezza di parola a 32 bit per calcoli più accurati, un minimo di 64K di memoria e possibilità di microprogrammazione. I “microprogrammi” venivano chiamati firmware, e contenevano software di controllo altrimenti realizzato in hardware; il firmware aveva una maggiore versatilità in caso di modifica delle specifiche di progetto. Alla fine fu scelto il sistema IBM 4Pi a causa della sua storia ed architettura: già utilizzato nelle applicazioni aeronautiche, aveva a che fare con i sistemi montati sullo Skylab e faceva parte della famiglia architetturale dei mainframe IBM 360. A causa della similitudine del set di istruzioni di AP-1 e del Sistema 360, i programmatori esperti del 360 erano praticamente pronti a lavorare sul progetto a costo di un retraining minimo. In più erano già disponibili numerosi tool di sviluppo per l’AP-1 sul 360. Infine, dal momento che lo Shuttle non avrebbe portato a bordo alcun tool di sviluppo né compilatore, era più conveniente eseguire i test del software a terra, dove esistevano simulatori AP-1 che giravano sui 360.
Una ulteriore caratteristica distintiva relativa ai computer del Progetto Shuttle rispetto a Gemini ed Apollo risiede nel linguaggio di programmazione: mentre infatti nelle precedenti missioni venne scelto di codificare i programmi in Assembly per avere sotto controllo la gestione di processore e registri in modo efficiente, per una questione di rapidità di sviluppo venne commissionato un linguaggio di programmazione ad alto livello che portò i costi di produzione del software ad un calo del 10%-15%. Curiosamente, il linguaggio di programmazione ad alto livello prodotto venne sviluppato dalla Intermetrics di Cambridge e chiamato HAL/S: esso supportava aritmetica vettoriale e task schedulati secondo un sistema di priorità definito dall’utente. Non è tuttora chiara la ragione della scelta del nome del linguaggio: il film di Kubrik, “2001: odissea nello spazio” era stato presentato nei cinema più o meno nel periodo di definizione delle specifiche di progetto. Ovviamente la NASA, come abbiamo visto in un’altra puntata, nega qualsiasi relazione tra il nome del compilatore e HAL 9000 presentato nel film; John R. Garman, del Johnson Space Center, uno dei principali responsasbili dello sviluppo di HAL/S, dichiarò una volta che l’origine del nome possa essere stata mutuata da un individuo incaricato del primo sviluppo, il cui nome era per l’appunto Hal. Altri suggeriscono che sia l’acronimo di Higher Avionics Language (gli Stati Uniti sono la terra degli acronimi, si narra che per evitare inutili e umoristiche esagerazioni abbiano sviluppato l’AAAA, Association Against Acronym Abuse…).
Uomini e macchine
La proposta di utilizzare HAL incontrò una notevole opposizione da parte di coloro che, oramai avvezzi a programmare in linguaggio macchina, ritenevano più lento, poco ottimizzato (quando non addirittura immorale) il codice prodotto automaticamente da una macchina. Oltre, naturalmente, ad essere proni ad errori di progettazione del sistema di codifica. In breve i compilatori non producevano codice bene come gli esseri umani: lo facevano semplicemente in modo più veloce ed accurato, ma senza quei guizzi di genio caratteristici della codifica manuale.
Per arginare eventuali critiche, Richard Parten, responsabile della Divisione Software dell’astronave, richiese una serie di benchmark: da una parte mise i migliori programmatori assembler di IBM, dall’altra chiese di produrre le medesime funzioni attraverso una codifica in HAL; fece poi girare le due batterie di programmi l’una contro l’altra, ottenendo una differenza di efficienza del 10% – 15%. La storia però non ci tramanda quale sezione fosse risultata maggiormente efficace…
Conclusioni L’esperienza ci ha insegnato che spesso l’incidente viene prodotto da qualcosa che semplicemente non viene previsto. Nell’incidente dell’Apollo 13 gli astronauti rischiarono di soffocare anzitempo perché Grumman e Rockwell, responsabili del modulo di comando e di allunaggio, avevano prodotto i condotti di aerazione l’uno circolare e l’altro quadrato, rendendo quasi impossibile il raccordo per la fruizione dell’ossigeno in casi di emergenza. Nell’incidente dell’Apollo 1 gli astronauti Gus Grissom, Ed White e Roger Chaffee morirono bruciati all’interno del modulo di comando pochi secondi prima del lancio per mancanza di estintore a bordo e di sistemi di apertura della porta dall’interno. Lo Shuttle Challenger, sul quale trovò posto la prima ed unica passeggera civile, la maestrina Christa McAuliffe, venne disintegrato durante la partenza a causa della perdita di una guarnizione di gomma del costo di pochi dollari. Nulla ci è dato ancora sapere sulle ragioni del fallimento della missione relativa allo Shuttle Columbia…
Rimane comunque il fatto che messo di fronte alle incognite di un viaggio spaziale, l’Uomo è stato in grado di cogliere la sfida e vincerla. Se quindi qualcuno avesse tuttora dubbi sull’importanza strategica, educativa e didattica dell’Informatica, potrà leggere a ritroso la storia dell’Uomo e trovarvi comunque la scintilla della conoscenza, la spinta verso l’ignoto e la passione per la curiosità come argomenti costanti della ricerca scientifica e umanistica. ( https://www.paginatre.it/ )
di Luigi Morelli
(27/07/2017)
ViaCialdini è su www.facebook.com/viacialdini e su Twitter: @ViaCialdini
