Il software dell’Apollo

By articolidiastronomia on 12/03/2022 • ( 1 commento )

Alla mia Mamma

Il 10 agosto 1961 la NASA affidò il primo appalto per il progetto Apollo al MIT, in particolare all’Intrumentation Laboratory (IL): l’obiettivo era di progettare un sistema hardware e software per la gestione del sistema primario di guida e navigazione (PGNS) chiamato AGC (Apollo Guidance Computer). AGC fu il primo computer digitale programmabile che usava i circuiti integrati realizzato sotto la direzione di Doc Draper, il direttore dell’IL, mentre Eldon Hall era il responsabile dello sviluppo hardware. Negli anni ’60 il termine software non aveva acora una definizione chiara: gli ingegneri avevano sempre progettato sistemi hardware, componenti meccanici o elettromeccanici e la scrittura di software era vista come un’attività secondaria con ruoli non ben definiti e stipendi più bassi degli altri. All’epoca mancava completamente una disciplina come ingegneria del software che potesse fornire le linea guida di sviluppo per la gestione di un progetto software, né corsi universitari dedicati.

L’architettura di base del AGC venne progettata da Hal Laning a partire da un prototipo che avrebbe dovuto essere sviluppato per un progetto di una sonda su Marte e successivamente ampliato: come spesso capita anche per i progetti odierni i requisiti inizialmente non erano ben definiti, anche se si conoscevano alcune basi e funzionalità con cui iniziare il lavoro, tra cui:

nessun sistema di ridondanza nel CM, ovvero nessun computer di back up: il software avrebbe dovuto essere estremamente affidabile; tuttavia, il LM invece disponeva di di un computer di backup con capacità molto limitata progettato dalla TRW.
La NAA (North American Aviation), che aveva in appalto la costruzione del CM, non aveva concesso molto spazio all’interno della capsula per l’alloggiamento del AGC. Il risultato finale l’AGC occupava circa un piede cubico, ovvero le dimensioni 55 cm x 33 cm x 15 cm con un consumo di 55 W: poco meno di una lampadina.

Il software dell’AGC si basava su un sistema di interrupt asincrono a priorità, ovvero ad ogni istante solo i task con più alta priorità per la situazione prevista in quel momento dal piano di volo erano in esecuzione: dopo di che il software scansionava una tabella in memoria per trovare il successivo task in ordine di priorità. Alcuni processi di base però come il timer, i campionamenti dei sensori e la telemetria erano sempre in esecuzione in background.

Secondo questo meccanismo l’AGC era caratterizzato da un comportamento non deterministico: non era sufficiente conoscere lo stato presente del sistema per prevedere quale fosse lo stato successivo

Questo comportava che l’intero sistema non era quindi predicibile, ovvero non è possibile sapere in anticipo quando terminerà ogni singolo sottoprogramma dato che non si può prevedere a priori se verrà o meno sospeso per gestire una seconda interrupt. Per questo motivo, allo scopo di evitare blocchi di esecuzione, il software era implementato in modo di fare un restart: per garantire coerenza e ripristino della situazione post-restart, i sottoprogrammi dovevano salvare il proprio stato di esecuzione.

Al fine di mantenere un rapporto stretto con lo sviluppo dei sistemi ingegneristici, il gruppo di sviluppo riceveva molto spesso la visita di astronauti e figure di primo piano del progetto Apollo e organizzava training a cui partecipavano anche i dirigenti della NASA dove venivano spiegate le basi del sistema di navigazione.

Come ogni progetto, era necessario anche testare il codice sviluppato: a questo scopo la NASA si avvaleva dei mainframe della Honeywell 1800 ed IBM 360 con pacchi di schede perforate usate per simulare le condizioni di operatività real-time della capsula nelle varie fasi di volo. La stampa delle schede occupava un periodo di tempo lungo, pertanto per ridurre i tempi, le schede venivano preparate in anticipo, spesso di notte, dagli ingegneri stessi sacrificando anche il week-end. Con il passare del tempo, si rese necessario integrare nel software di simulazione anche la gestione delle periferiche come la tastiera (DSKY), il pannello di controllo, la 8-ball creando così un sistema ibrido che riproducesse in maniera abbastanza fedele il comportamento che il software AGC avrebbe dovuto gestire ed interfacciarsi.

Dato la complessità crescente del software che gli sviluppatori dovevano gestire, si decise che ogni missione doveva avere un piano operativo (GSOP – Guidance System Operation Plan) contenente le specifiche del software per quella missione (release), la versione installata con le sue feature, la documentazione e quant’altro.

Diagramma con le varie release del software dell’AGC.
Fonte: Digital Apollo. Human and machine in spaceflight David A. Mindell

Ogni release finale del software conteneva due versioni: una installata nel CM (CGC – Command Guidance Computer) e l’altra nel LM (LGC – Lunar Guidance Computer). L’hardware era molto simile mentre le due versioni del software erano diverse e ognuna si occupava della gestione del modulo di propria competenza a seconda dello scopo; tuttavia, c’era anche una parte comune ad essi come, per esempio, il controllo di assetto (oggi queste unità di sviluppo si chiamano librerie di sistema). Con l’avvicinarsi della fine del decennio (anni ’60) il lavoro di sviluppo software divenne sempre più complesso e richiese sempre più risorse anno dopo anno: se nel 1965 al software lavoravano circa 100 persone, dopo il 1968 il numero dei programmatori era quadruplicato.

Fonte: Digital Apollo. Human and machine in spaceflight David A. Mindell

Il personale dedicato allo sviluppo software ed hardware crebbe durante il decennio passando da 100 dipendenti nella metà degli anni ’60 fino a raggiungeer 400 persone nel 1968, anno dell’Apollo 8. Dopo questa missione, che rappresenta una milestone importante per il progetto Apollo molti dei migliori tecnici iniziarono a lasciare la NASA, fondando una propria società. Nel gruppo comunque lavoravano persone di elevata competenza come Don Eyles, Margareth Hamilton e Hugh Blair Smith.

Margareth Hamilton, laureata in matematica, venne assunta dalla NASA nel 1963 come programmatrice e nel periodo di due anni divenne responsabile di tutto il software. Ella sosteneva che l’AGC doveva essere progettato per essere un sistema altamente affidabile, in grado di gestire ogni possibile situazione di errore in modo tale che autonomamente fosse in grado di uscire da una situazione di stallo come ciò che si verifico’ durante la missione Apollo 11. Per ben cinque volte durante la discesa del LM un allarme avverti’ gli astronauti mostrando sul display del DSKY i codici 1202 e 1201 e grazie alle decisioni prese a Huston l’equipaggio ricevette il GO per proseguire con l’allunaggio¹.

L’AGC riconobbe una situazione di saturazione della capacità e fu in grado di fermare tutti i processi in esecuzione, pulire la memoria e riavviarsi con i soli processi ad alta priorità previsti per quella fase di volo (allunaggio). In retrospettiva l’AGC non fallì mai, neanche durante la missione Apollo 12, quando durante l’ascesa del Saturn V venne colpito dai fulmini: l’AGC in seguito fu in grado di riavviarsi e ricaricare i dati corretti in memoria una volta entrato in orbita terrestre.

Hugh Blair Smith fu invece l’ingegnere ideatore del linguaggio assembler² (YUL) e del set di istruzioni grazie alle quali era possibile programmare con simboli mnemonici: il software veniva quindi tradotto in codice binario dai mainframe dell’IBM per poi esser cablato nei nuclei di ferrite all’interno della ROM dell AGC del LM e CM. Il software veniva memorizzato tramite operazioni hardware: la ROM consisteva in una serie intrecciata di fili che avvolgevano dentro e fuori un nucleo magnetico (memorie ad anello, core memory). Se fosse stato passante (filo interno al nucleo) allora avrebbe rappresentato un 1 in memoria, altrimenti 0: in tal modo il programma era indistruttibile e resistente anche ai fulmini. L’operazione di cablaggio venne appaltata alla Raytheon (un’azienda del Massachusetts che lavorava nel comparto tessile) e il lavoro di intrecciatura venne svolto a mano grazie alla pazienza delle dipendenti soprannominate LOL (Little Old Ladies) dell’azienda Raytheon. In seguito il processo di cablaggio venne parzialmente automatizzato grazie all’aiuto di macchinari tessili programmati con le schede perforate create dalo stesso programma che produceva il software (dall’azienda United Shoe Machinery Company del New England). Ogni missione aveva una differente versione del software e doveva essere pronta con largo anticipo prima del lancio (diversi mesi). Una volta cablato il software sulla memoria ad anello non c’era alcuna possibilità di modifica e la release veniva congelata.

I vari componenti dell’AGC Fonte: vedi bibliografia

Alla fine del 1968, circa sei mesi prima del primo allunaggio, il computer di bordo aveva ormai dimostrato di aver un ruolo centrale della missione essendo in grado di elaborare tutti i dati fondamentali del viaggio, con gli astronauti come supervisori con la possibilità in caso di emergenza di prendere il controllo manuale.

Il processo di sviluppo software nel complesso non si dimostro’ estraneo a problemi di ogni tipo: comunicazione , gestionale … ma nel complesso la NASA riusci’ a portare a casa il risultato. Come riportato in questo documento della NASA Questa lezione servi’ perlo sviluppo software dei progetti successivi, sottolineando l’importanza dei seguenti aspetti:

stesura della documentazione
definizione dei requisiti di progetto
creazione di un piano di sviluppo per release
piu’ programmatori non significa uno sviluppo piu’ veloce

Queste linee guida ovviamente sono valide anche oggi.

Note

1. Il codice assembler è un linguaggio di basso livello dipendente dall’architettura e dall’hardware della macchina sulla quale verrà fatto funzionare.

2. Nel manuale di riferimento, la descrizione del codice 1202 e 1201 è “No more core set” e “no more VAC Area“: questo significa che l’Executive non era in grado di assegnare memoria per il job che ne faceva richiesta (ogni processo allocava 11 word di memoria di lettura e scrittura) in quanto era esaurito lo spazio. Durante l’allunaggio non era possibile eseguire più di otto processi contemporaneamente, il software quindi fu in grado di annullare la richiesta (procedura di BAILOUT).

Bibliografia