Program Alarm 1202

Passando in rassegna tutti i documentari e film in cui viene drammatizzato l’allunaggio di Apollo 11, è indubbio che il momento di massima tensione è quello in cui viene descritta la serie di errori del computer che hanno caratterizzato la fase di discesa. Il senso di urgenza degli astronauti nel chiedere istruzioni, la frenesia dei controllori di volo a Terra di fronte a questo evento inaspettato … già, inaspettato … oppure no?!
La biografia di Gene Kranz e il bellissimo ‘Digital Apollo’ di David Mindell ci dicono qualcosa di diverso. E allora credo che la storia meriti di essere raccontata per come realmente si è svolta.

20 Luglio 1969, MET 102:38:26
Armstrong e Aldrin, a bordo del LM Eagle, hanno iniziato da alcuni minuti la fase PDI (Power Descent Initiate) con il LM orientato a faccia in giù, per poter monitorare i punti di riferimento sulla superficie dai finestrini. Proseguendo la manovra, ad un punto ben prestabilito, il LM ruota in modo da puntare il Landing Radar (LR) verso la superficie. Scopo dell’LR era quello di determinare altitudine e velocità del LM con una misura diretta da comparare poi con quella determinata dal computer sulla base delle misure inerziali. Era compito di Aldrin verificare che la discrepanza fosse entro un certo limite e accettare il valore del radar, di modo che l’AGC potesse incorporare questo nei suoi calcoli ed aggiornarsi. Appena Aldrin accetta, il Master Alarm suona e sul display del computer viene visualizzato l’allarme 1202.

Armstrong: “Program Alarm. It’s a 1202.”
Aldrin: “1202.”
Armstrong [rivolto al Controllo Missione]: “Give us a reading on the 1202”.

5 Luglio 1969 (11 giorni prima della partenza di Apollo 11)
Il team di Gene Kranz sta per affrontare l’ultima giornata di simulazione della fase di allunaggio: solitamente nell’ultimo giorno, per creare un buon livello di confidenza nel successo di una missione, le simulazioni hanno un livello di difficoltà minima.

Ma per quel giorno Dick Koos, un veterano dello Space Task Group e responsabile della simulazioni (SIMSUP, Simulation Supervisor) di allunaggio per Apollo 11, ha un altro piano:

“Attivate il caso nr. 26”.

Il Simulatore del LM

Nel corso della simulazione, giunti alla fase di PDI, l’AGC (Apollo Guidance Computer) del LM inizia a dare una serie di errori, Program Alarm 1201.
Steve Bales,controllore esperto del computer del LM, vede questo errore mai verificatosi in precedenza nelle simulazioni e nelle missioni reali. Anche per Alan Bean e Pete Conrad nel LM simulator questo errore è privo di significato.
Bales consulta il manuale dell’AGC a sua disposizione: il computer sta segnalando una condizione di overloading (sovraccarico), è al limite delle capacità operative. Chiede aiuto a Jack Garman (uno degli ingegneri dell’MIT che aveva lavorato all’AGC):

“Jack, what the hell is going on with those program alarm?”, “Jack, che diavolo sta succedendo con questi allarmi di programma?”

Garman può solo confermare che è una condizione di BAILOUT. Bales non aveva definito nessuna regola per un simile evento e, preoccupato che qualcosa di veramente critico stesse accadendo, decide di chiamare un Abort.

Nella riunione di debriefing, Koos infligge un duro colpo a Bales:

“Non era una condizione di Abort, avreste dovuto continuare con l’allunaggio”

E spiega che l’allarme 1201 indica che il computer ha iniziato a scartare alcun dei processi a priorità più bassi (ad esempio, aggiornare il display per gli astronauti) per poter continuare ad occuparsi di quelli a priorità alta (ad esempio, mantenere l’assetto del LM). Se il LM continua ad essere controllabile e a seguire la propria traiettoria significa che il computer è in grado di proseguire. Koos era anche convinto che Bales avesse capito tutto questo ed era rimasto sorpreso dalla sua decisione di abortire. Bales, devastato da queste notizie, reagisce istituendo al volo un gruppo di lavoro per definire delle regole per chiarire tutti i messaggi di errore possibili e come affrontarli. Si accorda anche con Koos per delle sessioni extra di simulazione nei giorni successivi per testare le nuove procedure.

Lo schema di Bales e Garman

9 giorni prima del decollo di Apollo 11, Bales aggiunge la Regola 5-90:

“Power Descent will be terminate for the following primary guidance system program alarms – 105, 214, 402, 430, 607, 1103, 1107, 1204, 1206, 1302, 1501 and 1502”

“La Power Descent verrà interrotta per i seguenti errori del programma primario di guida – 105, 214, 402, 430, 607, 1103, 1107, 1204, 1206, 1302, 1501 and 1502”.

Gli errori 1201 e 1202 non erano inclusi nella lista.
Anche Garman prepara per se uno schema con i dettagli da tenere alla sua console: aveva tutto quello che gli serviva in caso di bisogno per valutare la situazione.

20 Luglio 1969, MET 102:38:53
Nel giro di 10 secondi Steve Bales comunica che

“We’re go if it’s not recurrent”
“Possiamo continuare se non continua a ripetersi”

E aggiunge

“It’s the same thing we had”
“È la stessa situazione che abbiamo visto”

Il messaggio di Bales viene passato ad Armstron ed Aldrin dal CAPCOM Charlie Duke:

“We’re go on that alarm”
“Possiamo proseguire con quell’errore”

Duke commenta poi nel loop voce del MOCR(LINK):

“it’s the same one we had in training.”
“È lo stesso della simulazione”

Kranz, li accanto, è d’accordo e sorride.
Ne frattempo l’AGC nonostante la segnalazione di errore continua a funzionare correttamente, segnala un altro errore, un altro 1202, ma il LM risponde e reagisce perfettamente.
A 3000 piedi, l’AGC passa al programma P64 ed emette un altro allarme, stavolta il 1201. Duke (su segnalazione di Bales) comunica

“Same type, we’re go”
“Stesso tipo, possiamo continuare”

In tutto si verificano 5 errori (seguiranno un altro 1201 e un 1203). Successivamente, a causa delle condizioni del luogo di allunaggio programmato, Armstrong (il cui battito cardiaco è arrivato a 150 battiti al minuto) passa al controllo manuale del LM, programma P66. E pochi minuti dopo il LM si posa sulla superficie senza ulteriori problemi.

20 Luglio 1969 (subito dopo l’allunaggio). Il telefono dell’IL (MIT Instrumentation Laboratory), il laboratorio dove lavorano i progettisti e realizzatori dell AGC e del software suona ogni 15-30 minuti. La NASA vuole sapere cosa è successo. Inizia una frenetica sessione di simulazione per ricreare l’errore e capire cosa lo possa aver causato.

Il Simulatore del LM

George Silver, uno degli ingegneri dell’IL, ha seguito l’allunaggio e ha la risposta: ha visto il problema in una simulazione dell’AGC, a causa dal Rendevouz Radar (RR) acceso in posizione AUTO durante la discesa. In questa modalità l’equipaggio dirige l’antenna verso il CSM e poi il radar lo continua a tracciare in modo automatico. Aldrin aveva chiesto se era possibile tenere il RR acceso in AUTO durante la discesa (in caso di abort di emergenza) e aveva ottenuto l’OK dall’IL. Nel corso delle simulazioni non si era verificato nessun problema poichè non c’era un vero RR collegato all’AGC e quindi nessun carico di lavoro supplementare. Ma nel vero Eagle l’RR c’era ed era alimentato da un diverso alimentatore rispetto al resto dei sistemi di guida, un alimentatore in corrente alternata con una fase diversa: un angolo di fase veramente sfortunato, che non permetteva all’AGC di sincronizzare facilmente la lettura dei dati dell’RR.
L’AGC era stato progettato per operare all’85% della sua effettiva capacità, mantenendo l’ultimo 15% come ‘scorta’. Il problema di lettura dell’RR consumò questo margine di sicurezza. Come evidenziato da Koon, sempre per scelte progettuali, in queste condizioni l’AGC prima scartava le operazioni a bassa priorità e se questo non bastava si riavviava in maniera istantanea senza perdita di dati. Questo avvenne per tutte e 5 le condizioni di errore in Apollo 11.
Anche il programma in esecuzione ebbe un impatto sul problema: P64 richiedeva molta potenza di calcolo e quindi più lavoro per l’AGC. P66 invece ne richiedeva molto meno ed infatti appena passati a questo programma gli errori finirono.

Due ultime note:

• Aldrin non sapeva nulla dell’ultima simulazione ed ebbe a dire
  

  “it seems as through that was a flaw in communication. I was very much in the dark when this came up”
  “Sembra che ci sia stata una mancanza nella comunicazione. Ero totalmente al buio quando questi [gli errori] saltarono fuori”

• Bales venne premiato, con la stessa medaglia data agli astronauti, per la sua chiamata. Nella motivazione venne contrapposto il comportamento errato del computer all’eroico sforzo dell’equipaggio e di Bales per l’allunaggio. I ragazzi dell’IL non furono molto felici di questo e non a torto. In fondo era stato proprio il loro ottimo lavoro di progettazione dell’AGC e del suo software che aveva invece salvato la missione grazie alla sua capacità di ‘ripartenza morbida’.