AGC: un piccolo passo per l’uomo ma un grande passo per l’informatica

La notte in cui quasi non scendemmo sulla Luna.

Per ragioni che racconterò in un prossimo post, da mesi sto leggendo con attenzione le trascrizioni di tutte le comunicazioni tra il mission control di Houston e gli astronauti delle missioni Gemini e Apollo per trovare riscontri nelle sequenze di programmi e comandi inseriti nell’AGC, il computer di bordo di queste missioni.

L’AGC è una macchina meravigliosa che per qualche ragione non trova spazio nella letteratura di retrocomputing al di fuori degli appassionati di astronautica. È lui il primo eroe di questa storia.

L’AGC Block 1 è stato uno dei primissimi computer a fare uso di circuiti integrati e certamente è stato il più compatto della sua epoca (misurando 61x32x15cm e pesando “solo” 30kg). Un vero gioiello della tecnologia, studiato per sostituire i computer a terra che occupavano intere stanze e avevano bisogno di una centrale elettrica dedicata.

Si trattava di un computer realtime (!), multitasking (!!!) con bus e “CPU” a 16 bit (15 di dati e uno di parità), dotato a seconda della release di circa 65-70KB ROM (tra 32k e 38k word da 15 bit) sotto forma di core rope memory e 3.8KB RAM (2048 parole da 15 bit). Grazie al fatto che ciascun core ospitava 64 fili discreti, i 600.000 bit necessari alla macchina occupavano meno di 10.000 core, risparmiando parecchio spazio (che nello spazio infinito, paradossalmente, è una cosa buona come nello spazio finito di casa nostra). Assorbiva solo 2.5A a 28V per 70W di potenza e, per dare una scala dimensionale, aveva una capacità di calcolo equiparabile a quella della triade del ’77. Solo quindici anni prima.

Anche se l’uso della logica integrata si limitava a 2.800 NOR gates duali (prodotti da Fairchild Semiconductor) impiegati come flip flop per i registri centrali della CPU, la scelta di limitarne l’adozione nell’AGC fu presa con consapevolezza. Poiché il precedente sistema di guida (il Minuteman II) usava anche una logica diodo-transistor e diodo-diodo ma aveva dato troppi problemi di affidabilità a terra, non ci si fidava a portarlo in volo.

La CPU dell’AGC non era in logica IC; senza riaprire l’eterno dibattito sulla paternità dei microprocessori  (sappiamo che la logica integrata arriverà solo con il progetto di Ray Holt e l’Intel 4004) non è che alla Grumman non ci avessero pensato (sì, proprio la Grumman che pochi anni dopo avrebbe commissionato alla Garret il microprocessore di Holt… vi si stanno unendo i puntini?); al contrario, avevano valutato attentamente la possibilità di adottare in toto circuiti integrati e di sviluppare una CPU RTL per la quale avevano anche studiato le possibili strategie di produzione. Come scrivevo, però, la logica integrata era troppo nuova e non dava certezze per le condizioni estreme della fase di ascesa, volo e rientro. Per questa stessa ragione tutta la componentistica dell’AGC era wire wrapped e poi affogata in plastica epossidica. Una cosa che in nome della correttezza storica e a dispetto del costo irrisorio dei singoli componenti, sta facendo crescere in modo significativo il costo del mio progetto!

Comunque, questa meraviglia della tecnologia, un salto tecnologico enorme concepito all’inizio degli anni sessanta e provata in volo appena sei anni dopo, è forse la parte meno appariscente delle missioni Apollo e tuttavia è al centro della missione stessa e – in almeno due casi – della salvezza degli astronauti.

Una delle due storie la conosciamo tutti: qualcuno l’ha vissuta in tempo reale nel 1970 mentre a noi altri troppo piccoli o nemmeno nati, è stata raccontata da libri, documentari e dal film Apollo 13. L’esplosione di un serbatoio dell’ossigeno a causa di un corto circuito mise a repentaglio la vita dell’equipaggio e solo la fantasia ingegneristica del personale di terra li tenne in vita grazie a calzini, tubi e… alla quadratura del cerchio.

Quella che vi racconto adesso invece riguarda l’Apollo 14, in particolare le ore che hanno preceduto fase di discesa del LEM con a bordo Alan Shepard e Ed Mitchell.

Sono le 10:05 del mattino in Italia ma nello spazio, per gli occupanti del modulo di comando Kitty Hawk che si apprestano a salire a bordo dell’Antares per scendere nell’altopiano di Fra Mauro, è notte. Una notte schizofrenica, indecisa tra il buio più nero e la luce accecante riflessa dalla Luna. Ed Mitchell, che avrebbe pilotato il LEM verso l’altopiano di Fra Mauro, stava effettuando gli ultimi controlli sui computer di bordo dell’Antares mentre Al Shepard – il comandante nonché mito vivente dell’astronautica americana – scorreva la
lista dei check con fredda professionalità e rapidità. C’era molto da fare prima di iniziare la gita che tutti al mondo avrebbero voluto (e vorrebbero) fare.

A bordo del LEM, oltre all’AGC erano presenti altri computer indipendenti e specializzati. Non erano programmabili come l’AGC ma avevano invece un programma prestabilito e essenziale per ciascuna fase di volo. In quel frangente della missione, in ordine alla sicurezza del volo, il più rilevante di questi sistemi funzionali era l’AGS (Abort Guidance System). Si trattava del computer deputato all’annullamento della fase di atterraggio a seguito di un problema grave (spegnimento del motore principale, perdita dell’assetto, avarie di altra natura). Ogni 250 millisecondi una routine del’AGC verificava se fosse stato premuto uno dei due pulsanti ABORT o ABORT STAGE; se quello fosse stato il caso, la routine avrebbe impostato un segnalatore discreto che autorizzava l’AGS a prendere il controllo dell’astronave e a dare il via alle manovre di ascensione di emergenza attivando il programma 70 (risalita con motore principale) o il programma 71 (risalita da stage intermedi).

Mitchell continuava a digitare le sequenze di controllo sul DSKY, l’interfaccia utente dell’AGC (la prima interfaccia per computer di cui sia documentato l’approccio UX e di ergonomia funzionale); l’AGC era un computer semplice da programmare e usare, almeno per gli standard dell’epoca. L’immissione di comandi avveniva attraverso codici numerici che si riferivano a un VERB (un’azione o comando) e a un NOUN (l’oggetto di quel comando) seguiti da eventuali parametri in notazione ottale. L’intero ciclo di volo consisteva in una sequenza di programmi indipendenti, a volte attivati manualmente a
volte attivati automaticamente al verificarsi di determinate condizioni e l’attività degli astronauti andava dal richiamare questi programmi al passare loro dei parametri calcolati a bordo o a terra (i famosi valori delle “calcolatrici umane” di cui parla il film “Il diritto di contare”).

Mitchell continuava nella digitazione di comandi di impostazione e poi comandi di verifica che mostravano sul display a segmenti le informazioni di controllo, mentre la telemetria replicava i risultati perché potessero essere analizzati e confermati a terra.

Poco dopo la fase di distacco dal modulo di comando, proprio la telemetria iniziò a segnalare frequenti set e reset dei segnalatori discreti di ABORT, come se gli astronauti stessero premendo compulsivamente uno dei pulsanti di annullamento di emergenza della discesa. Ci vollero pochi secondi per capire che si trattava di un corto circuito intermittente dovuto probabilmente al distacco di un cavo durante le fasi di decollo e di inserimento in rotta. Ancora una volta un maledetto corto circuito per un cavo rotto, a dimostrazione della violenza con la quale la navicella veniva squassata nelle fasi intense del decollo.

La missione era a rischio e forse anche la vita degli astronauti, in balia di una potenziale accensione indesiderata dei sistemi di risalita se non addirittura del motore principale.

Nonostante il rischio, si decise di proseguire ancora per un po’ la missione poiché il pericolo non era immediato; il sistema di volo aveva infatti una sorta di protezione, un flag di autorizzazione all’annullamento (il flag LETABORT), che veniva attivato solo durante l’esecuzione di certi programmi e non di altri (nello specifico il programma P70 e il programma P71). Nel frattempo, a terra, gli ingegneri iniziarono a lavorare a un workaround (non essendo possibile una riparazione in volo).

Inizialmente qualcuno pensò di forzare un reset del flag LETABORT così da impedire alle procedure di annullamento di entrare in funzione. Dopo le prime verifiche questa strada non si rivelò applicabile per almeno due ragioni: la prima è che l’accensione del motore di discesa comportava l’attivazione automatica del flag LETABORT! Gli astronauti avrebbero dovuto re-immettere nell’AGC la sequenza di comandi di reset perdendo una decina di secondi durate i quali, se si fosse verificato il cortocircuito, le procedure sarebbero entrate in gioco con la navicella in assetto ancora orizzontale, lanciandola probabilmente fuori dall’orbita. La seconda è che… se si fosse davvero resa necessaria la procedura di annullamento, gli astronauti avrebbero dovuto ripristinare il flag e ripetere l’intera procedura normale di accensione del motore prima di poter passare al programma P70 (ascesa di emergenza con il motore principale) o P71 (ascesa in uno degli altri stage del programma di discesa), perdendo secondi preziosi e potenzialmente fatali!

Gli astronauti avevano ricevuto una breve segnalazione in merito a una possibile variazione della procedura di discesa ma non erano ancora stati informati della serietà della situazione e quindi proseguivano le loro attività come da piano di volo.

La Luna non ha un’atmosfera che oppone resistenza a una nave spaziale, così il LEM era stato progettato per il massimo contenimento del peso. Ogni kg di massa risparmiata forniva qualche secondo in più di spinta e controllo al pilota e ogni secondo di controllo in più poteva significare la differenza tra la vita e la morte. Pertanto, alla ricerca della leggerezza estrema, una buona parte della “carrozzeria” del modulo lunare, consisteva in un sottile foglietto di alluminio non troppo diverso da quello con il quale cuociamo il pesce al cartoccio nel forno. Chiusi nel loro piccolo ambiente, separati dallo spazio infinito da una tovaglietta di carta stagnola, Mitchell e Shepard continuavano le loro manovre, programma dopo programma.

Ma il tempo stringeva: rimanevano meno di tre ore per trovare una soluzione per evitare di dover annullare la missione e non far correre rischi all’equipaggio. La pressione era tantissima.
Dopo i successi dell’Apollo 11 e dell’Apollo 12, l’Apollo 13 aveva fallito e sebbene l’essere riusciti a riportare a casa gli astronauti sani e salvi avesse accresciuto il senso di orgoglio e il supporto alla NASA da parte della popolazione americana, negli ambienti politici si era già messa in dubbio l’utilità di queste missioni a fronte dei costi elevati e in considerazione del fatto che la gara contro i russi era stata ormai vinta. Un secondo fallimento consecutivo avrebbe potuto minare l’intero programma spaziale.

L’Antares ormai si approssimava all’inizio della fase di correzione dell’assetto per lo stage finale di discesa e gli ingegneri dell’MIT a terra dovevano ancora elaborare una procedura, comunicarla alla Grumman a Houston per i test e poi farla trasmettere dal mission control agli astronauti.

Circa trenta minuti prima della scadenza del tempo utile entra in campo il secondo eroe di questa storia, Don Eyles, uno degli sviluppatori del software dell’AGC del LEM (il software “Luminary”). Conoscendo profondamente il funzionamento dell’AGC e dei suoi programmi di volo trovò una via d’uscita nel MODEREG, uno dei 13 registri addizionali della CPU dell’AGC.
Questo registro indicava la locazione di memoria che conteneva il numero del programma attualmente in esecuzione (il cosiddetto “major mode”, nel gergo dell’AGC). Il suo scopo era principalmente quello di dare al DSKY l’informazione affinché la mostrasse agli astronauti sul display a segmenti. Per fortuna quello stesso registro veniva interrogato anche dall’AGS per verificare che i programmi 70 o 71 non fossero già in funzione al momento della richiesta di annullamento della procedura di discesa (in tal caso non avrebbe avuto senso attivare una
procedura già in esecuzione!).

Ecco che in pochi minuti il piano prese forma: si doveva ingannare la routine di controllo dell’annullamento inserendo P71 nel MODEREG dopo aver manovrato per mettere il LEM in posizione corretta per l’accensione del motore di discesa; si sarebbe poi atteso che il
motore, accendendosi, avesse impostato il flag LETABORT e lo si sarebbe quindi resettato; se il cortocircuito si fosse verificato nei 10 secondi necessari per la procedura, la routine di controllo dell’annullamento avrebbe trovato P71 nel MODEREG e non avrebbe lanciato il programma di ABORT. Una volta resettato il flag LETABORT, gli astronauti avrebbero ripristinato il MODEREG corretto e proseguito la discesa.

Come in un film pieno di suspense, il test presso la Grumman però fallì! Si riconobbe che anche la routine di accensione del motore aveva le sue esigenze e, in particolare, si aspettava di trovare nel MODEREG il Programma 63 o non avrebbe portato il motore alla massima potenza dopo i 26 secondi necessari al vettoramento di spinta per la correzione dell’assetto; soprattutto non avrebbe impostato il flag ZOOMFLAG che segnalava al sistema di discesa di prendere il controllo e portare l’astronave sulla superficie!

La soluzione non funzionava ma la strada era segnata. Per circa 20 minuti gli ingegneri lavorarono a una procedura rivista tenendo conto di tutti i vincoli noti; una decina di sviluppatori ripercorrevano i diagrammi di flusso dei
programmi coinvolti e le interazioni tra i sistemi con frenesia e alla fine arrivarono alla soluzione: il pilota avrebbe impostato il P71 nel MODEREG e effettuato le manovre normali fino all’accensione del motore e ai successivi 26 secondi necessari per completare la correzione d’assetto. Quindi il comandante avrebbe portato la manetta al massimo facendo l’override del sistema automatico mentre il pilota avrebbe contestualmente impostato lo ZOOMFLAG per poi resettare il flag LETABORT e reinserire P63 nel MODEREG. A questo punto Shepard avrebbe riportato la manetta al minimo e il computer di discesa avrebbe preso il controllo. Il vantaggio di questa procedura era che per eseguire una manovra di interruzione di emergenza, l’equipaggio avrebbe dovuto semplicemente alzare il flag LETABORT e premere il pulsante di interruzione appropriato. Pochi istanti.

La flessibilità, programmabilità e usabilità dell’AGC, l’intuizione di un brillante sviluppatore che lo conosceva profondamente e l’addestramento degli astronauti sono il primo esempio di workaround della storia. A 380.000km da qui.

La prossima volta che alzerete gli occhi al cielo e guarderete la Luna, date una sbirciata all’altopiano di Fra Mauro e pensate a quel piccolo grande AGC che è lì, in attesa che un retrocollezionista vada a recuperarlo

P.S.

L’immagine che accompagna questo post, è la trascrizione di quel minuto e ventisette secondi durante i quali tutto sarebbe potuto andare male e invece un piccolo magico computer e un ingegnere che lo amava, salvarono la missione e forse la vita di quegli uomini coraggiosi avvolti in un foglio di carta stagnola.

La sigla CC sta per Cap Com, il contatto radio a terra che per questa missione era Fred Haise (il pilota del modulo LEM dell’Apollo 13 e che nel film prende l’influenza).
LMP-LM sta per Lunar Module Pilot, cioè Ed Mitchell che riuscirà a scendere sulla Luna e a trascorrere complessivamente quasi nove ore passeggiando come mai più nella sua vita.
Infine CDR-LM sta per CommanDeR of Lunar Module e si riferisce a Alan Shepard, un mito assoluto, primo americano nello spazio, il decano degli astronauti a stelle e strisce. Uomo tutto d’un pezzo capace comunque di uscite meravigliose come quella prima del decollo del razzo Redstone che lo avrebbe portato in orbita sulla Freedom 7: “Please, dear God, don’t let me fuck up”. E come dimenticare la sua partita a golf sulla Luna?
Di lui ci rimane anche l’omaggio videoludico nella serie “Mass Effect”. È proprio lui il Commander Shepard!

La sequenza di comandi workaround l’ho segnata in rosso e numerata per agevolarvi la ricostruzione degli eventi:

1) Dopo che il countdown del NOUN 62 parte (62s che sta per “NOUN 62 starts”) Mitchell digita

VERB 21 NOUN 1 ENTER 1010 ENTER 107 ENTER

cioè lancia il comando di LOAD (VERB 21) all’indirizzo 520 (1010 ottale, l’indirizzo di un registro del display del DSKY che copia il valore del MODREG – che in realtà ha indirizzo 500) del valore 71 (107 ottale). Cioè mette nel MODREG letto dalla routine di annullamento l’indicazione che il programma in esecuzione è il programma 71.

2-3-4) Dopo 26 secondi esatti dall’accensione del motore principale Shepard porta la manetta a fondo scala (in realtà è di due secondi in ritardo…)

5-6) Mitchell quindi digita :

VERB 25 NOUN 7 ENTER 101 ENTER 200 ENTER 1 ENTER

cioè il comando LOAD (VERB 25, un comando LOAD diverso dal precedente) una maschera di bit (NOUN 7) data dai valori ottali 101 200 1 che di fatto attiva le equazioni di discesa per l’atterraggio.

7) Poi digita

VERB 25 NOUN 7 ENTER 105 ENTER 400 ENTER 0 ENTER

che disattiva il monitoraggio dell’annullamento abbassando il flag LETABORT e alzando il flag ZOOMFLAG

8 ) Poi digita

VERB 21 NOUN 1 ENTER 1010 ENTER 77 ENTER

per rimettere il MODREG al suo valore normale 63 per permettere al sistema di guida di prendere il controllo.

Il resto dei comandi del punto 8 attiva il radar di atterraggio. Quando tutta la procedura si conclude e il sistema di guida ha preso il controllo, Mitchell chiede a Shepard di portare la manetta al minimo.

“Okay. It’s coming down” (riferito alla manetta ma è bello pensare al LEM che scende sicuro verso la superficie). Tutto è bene quel che finisce bene!

Se qualcuno volesse provare al volo l’AGC senza entrare nelle complessità del progetto Virtual AGC, trovate un ottimo simulatore online qui:

http://svtsim.com/moonjs/

In tal caso noterete che dopo aver inserito il comando di clear del flag LETABORT e di accensione di quello ZOOMFLAG, l’indicatore della manetta rimane al massimo. Questo avviene, ovviamente, perché rimettendo il MODREG a 63 il sistema di guida prende il controllo e siamo ancora in una fase del programma di volo nel quale la spinta è massima per ridurre la velocità della navicella. Allora perché Shepard dovette mettere la manetta al minimo se il sistema comunque l’avrebbe tenuta al massimo? Perché la manetta al massimo forzava l’override del sistema di controllo e quando questo in seguito avrebbe dovuto parzializzare la spinta, trovando un override con manetta al 100% l’avrebbe invece tenuta al massimo facendo un casino inenarrabile.