Q&A: Comunicazioni con l’Apollo

Ecco alcune risposte riguardo le domande che mi sono arrivate riguardo le comunicazioni tra la capsula Apollo e il centro controllo missione di Houston (MCC): cercherò di spiegarlo con parole adeguate. 

Domanda: anche l’Olivetti partecipò allo sbarco sulla Luna?

Un riferimento affidabile si può trovare in questo articolo dell’IEEE (serve account) Effettivamente sono state utilizzate Olivetti P101 per la fase di allunaggio nella missione Apollo 11 ma non ho trovato in che ruolo ed in che parte del progetto. (tipo di calcoli e in che fase di volo) L’Olivetti fornì “nel pacchetto” anche una libreria dei programmi più usati. La P101 poteva essere affittata per 3200$ (degli anni ’60), mentre i mainframe IBM System/360 avevano un affitto variabile da 2700$ a 115000$


Essendo i mainframe IBM multiutente e multiprogrammazione posso pensare (mia ipotesi) che mentre la P101 era un “computer desktop” che veniva usata dai tecnici per eseguire calcoli in maniera “ad personam” senza aspettare i tempi di allocazione delle risorse dei mainframe così da avere già dei risultati validi da cui partire per magari fare analisi più approfondite (l’occupazione dell’uso di un mainframe viene gestito da code di allocazione a seconda della priorità del task, dell’urgenza, tipo di accesso … un po’ come per i telescopi virtuali o come veniva fatto all’inizio per Hubble)


Domanda: Era possibile ascoltare le comunicazioni Apollo?

Achille e Giovanni Judica Cordiglia: avevo già sentito parlare dei fratelli in occasione del volo di Yuri Gagarin e altro legato all’astronautica sovietica ma non ho mai trovato in giro una documentazione che parlasse del loro lavoro o di qualche pubblicazione. Ho trovato però questo, link che si riferisce al tracking da Terra della missione Apollo 17. Quindi era possibile ascoltare gli astronauti dell’Apollo ma se i fratelli fossero in grado o l’abbiano fatto non ho trovato documentazione.

Per gli amanti della fotografia sappiate che il CSM + S-IVB (terzo stadio del Saturn V) è stato fotografato da Terra durante l’accensione motori che lo ha immesso nella TLI (https://airandspace.si.edu/stories/editorial/photographing-apollo-8s-orbit-toward-moon) così come nella fase di rientro in atmosfera (https://www.space.com/19250-apollo-8-reentry.html).


Domanda: In che modo avvenivano le comunicazioni Terra-Apollo?a

In generale le comunicazioni viaggiavano in due bande:

  • Banda S su cui viaggiavano i dati di telemetria, comandi da inviare all’AGC, radar (per il calcolo distanza & velocità), TV Per questo motivo l’hanno chiamata banda USB (Unified-S-Band)
  • Banda VHF

Visto la precisione richiesta per la determinazione di posizione e velocità gli orologi erano complessi (stabilità in frequenza, indipendenza dalle variazioni termiche …) e pesanti, quindi non potevano essere presenti sul CSM. Il calcolo distanza e velocità veniva usato il radar e veniva sfruttato l’effetto Doppler. Il segnale trasmesso e ricevuto viaggiava su 2 frequenze (portanti) diverse in rapporto fisso fra loro e noto (chiamiamole f_{up} e f_{down}). La variazione di frequenza era continua, ovvero se la frequenza di ricezione aumenta, il CSM si avvicina; viceversa se diminuisce il CSM si allontana.

I valori delle portanti sono:

  • CSM : 2106,4 MHz
  • LM : 2101,8 MHz

Rapporto di ricezione:

f_{down} = \frac{240}{221} * f_{up}

In questo link ci sono altri dettagli. I valori decimali sono leggermente diversi, invece coincidono con quanto riportato qui https://www.honeysucklecreek.net/images/pdfs/HSK_Apollo_Simulation_System.pdf paragrafo 2 (Mission Configuration).

C’è anche questo NASA Technical Note https://www.hq.nasa.gov/alsj/tnD6739VoiceCommTechnqs.pdf che presenta una descrizione dei parametri di trasmissione utilizzati per il progetto Apollo. Distingue diversi casi:

  • comunicazioni fra astronauti-Houston quando CSM in orbita LEO intorno alla Terra
  • comunicazioni fra astronauti-Houston quando CSM in orbita intorno alla Luna
  • comunicazioni fra astronauti-Houston quando CSM in viaggio da/per la Luna
  • comunicazioni fra astronauti-Houston quando sono sono sulla Luna

Le caratteristiche delle antenne sono diverse.

Fonte: Apollo experience report voice communications techniques and performance, 1972 NASA (link)

Alcune abbreviazioni usate: 

  • TLI (Trans Lunar Injection) è la manovra (accensione motori) eseguita sotto controllo dell’AGC che porta il CSM + terzo stadio S-IVB lungo l’autostrada gravitazionale che porta verso la Luna. A seconda della missione è stata usata una traiettoria ibrida o di ritorno libero (FRT, Free Return Trajectory)
  • TEI (Trans Earth Injection). Uguale alla precedente ma dalla Luna alla Terra.

Correzioni di orbita del CSM sono possibili per:

  • corretto punto di ammaraggio e recupero
  • corretta sincronizzazione con la rotazione terrestre.

Altri termini:

  • MSFN: è l’acronimo di Manned Space Flight Network (o misfin). Un sistema di stazioni di Terra per seguire l’Apollo intorno alla Terra. Simile al DSN ma quest’ultimo usato per comunicare con gli astronauti quando sono molto distanti (sulla Luna). Come si vede dalle figure si utilizzano strumentazioni diverse (ad esempio diverse antenne)
  • VOX: è un circuito che attiva il trasmettitore. Appena l’astronauta inizia a parlare inizia anche la trasmissione. Proprio per questo poteva succedere che le prime sillabe del parlato non venissero trasmesse.
  • PTT (Push-to-talk): significa che chi trasmette deve premere un pulsante per parlare. In ogni caso, anche quando gli astronauti non parlavano la comunicazione non veniva interrotta in quanto i dati di telemetria continuavano a venire trasmessi.

Domanda: Che protocollo veniva usato up/down link?

In ogni fase di volo solo un insieme di programmi è in esecuzione sull’AGC (quelli previsti con la priorità più alta, come dicevamo nella conferenza), quindi i dati trasmessi a terra sono relativi ai programmi che sono attivi in quel momento ottenuti con un “memory dump” (una fotografia istantanea del contenuto della memoria) parziale in modo da trasmettere con maggior frequenza (nel senso più spesso) sul canale di telemetria.

  • downlink: vengono trasmesse info (200 Word) divise in info sul vettore di stato (ovvero: “dove mi trovo?”), status dei flag e il valori del DSKY (100 Word) e altre 100 Word a seconda del Major Mode. Queste 200 Word vengono trasmesse in pacchetti di 40 bit a Terra dove si include un ID (immagino ID del pacchetto), una stringa di sincronizzazione, un Word Order Code ed il contenuto dei canali/registri  interessati.  Il processo di downlink viene gestito dall’AGC con un interrupt ogni 20 ms. La formattazione ed invio  di tutti pacchetti (200 Word) impiega 2 secondi, poi si ricomincia con un altro set di 200 Word. Esistono casi in cui a seguito di un comando particolare sul DSKY viene fatto il dump dell’intera memoria (2048 Word)
  • uplink: serve per inviare e impostare (modificare) comandi nell’AGC. Usa lo stesso formato VERB/NOUN usato dagli astronauti. Prima di inviare qualsiasi dato gli astronauti devo però impostare il computer in modalità “Accetta comandi remoti”, questo anche per motivi di sicurezza senno riceverebbe dati da chiunque compreso i sovietici …. Come se fosse un comando “manuale” i dati sono formattati con 3 pacchetti da 5 bit, più altri 7 bit come parte del comando di update. In totale un update da Terra occupa 22 bit per “tasto”. Alla ricezione del pacchetto, l’AGC del CM/LM invia un pacchetto ACK di 8 bit. Alla fine della trasmissione (cioè quando è inviato l’ultima sequenza dell’ultimo tasto del DSKY) su DSKY lampeggia un codice. Se tutto OK, l’astronauta accetta e i dati sono caricati in AGC.

VERB/NOUN era la sintassi usata da tastiera (DSKY) per dialogare con AGC.

Bibliografia

  • How Apollo flew to the Moon” David Woods, Springer
  • The Apollo Guidance Computer: Architecture and Operation” Frank O’Brien

Il codice sorgente dell’AGC

Il codice sorgente dell’AGC montato a bordo del CM e del LM per la missione Apollo 11, da circa dieci anni è liberamente disponibile e consultabile grazie al lavoro di Chris Garry, ex dipendente della NASA, che ha dedicato tempo a scansire e copiare i sorgenti in formato testuale (con estensione agc) e pubblicarli in un repository sulla piattaforma GitHub.

Dark Mode

Apollo-11 (this link opens in a new window) by chrislgarry (this link opens in a new window)

Original Apollo 11 Guidance Computer (AGC) source code for the command and lunar modules.

Puntando il browser all’indirizzo qui sopra si apre il repository nel quale si tovano due directoy principali con i commenti dei programmatori originali.:

  • Comanche055: il quale contiene il codice sorgente Colossus 2A (CM)
  • Luminary099: il quale contiene il codice sorgente Luminary 1A (LM)

Il linguaggio mnemonico usato si chiama YUL (assembler) il cui formato di ogni istruzione rispecchia la sintassi

<etichetta> <istruzione> <commento>

I token <etichetta> e <commento> sono opzionali. Il seguente estratto ad esempio:

ERRORS          INHINT
                CA      Q
                TS      SFAIL           # SAVE Q FOR FAILURE LOCATION

preso dal file AGC_BLOCK_TWO_SELF-CHECK.agc è costituito da tre istruzioni (una per riga). La prima riga rispecchia la sintassi <etichetta> <istruzione> e possiede il seguente significato:

  • ERRORS: nome dell’etichetta, ovvero riferimento di rimando nel codice.
  • INHINT: istruzione, per disabilitare le interruzioni. Nell’AGC tutti i task che richiedevano una temporizzzazione critica o lavoravano con dati in aree di memoria sensibili dovevano disabilitare le interruzioni per consentire loro di portare a termine il task in un periodo di tempo noto.

La seconda riga contiene solo il token <istruzione> con il seguente significato:

  • CA Q: azzera l’accumulatore e aggiungi il contenuto del registro Q (registro di stash).

La terza riga ha il formato <istruzione> <commento> e possiede il seguente significato:

  • TS SFAIL: Trasferisci il contenuto dell’accumulatore nella locazione di memoria SFAIL

Come descrive il commento (la stringa che segue #), queste tre istruzioni nel complesso mostrano la procedura di salvataggio dati e disabilita gli interrupt all’inizio della subroutine ERRORS.  In caso di cambio di contesto l’AGC non aveva la possibilità di gestire lo stack, quindi tutti i passaggi per il salvataggio di registri dovevano essere gestiti dal programmatore. In generale all’interno del codice sorgente si trovano numerose annotazioni dei programmatori dell’epoca che descrivono le funzioni dei singoli comandi o blocchi di codice. Questo accorgimento è considerato anche oggi una buona prassi di programmazione a patto di accompagnare il codice con commenti pertinenti. I commenti che si trovano nei sorgenti dell’AGC sono invece molto vari: alcuni commenti sono un po’ poetici e mostrano la creatività degli autori e vanno oltre il linguaggio tecnico .


Sebbene il listato originale sia costituito come un blocco monolitico ovvero come un unico blocco funzionale, nel repository l’autore lo ha riorganizzato in moduli al fine di migliorarne la leggibilità. Per un’analisi del listato si consiglia di partire dai file seguenti:

  • file MAIN.agc di ogni modulo (Luminary e Comanche) che spiega come è strutturato il codice. Ognuno di questi due moduli contiene la suddivisione logica in moduli funzionali del software con le pagine di rimando nel caso di una ricerca veloce all’interno dello stesso. Qui sotto per esempio c’e un estratto del MAIN.agc del Luminary (Colossus 2A)
$ASSEMBLY_AND_OPERATION_INFORMATION.agc         # pp. 1-27
$TAGS_FOR_RELATIVE_SETLOC.agc                   # pp. 28-37
$CONTROLLED_CONSTANTS.agc                       # pp. 38-53
  • file CONTACT_AND_APPROVALS.agc che contiene le informazioni generali del progetto. In testa al file nella maschera d’intestazione si legge il seguente commento:
#         SUBMITTED:    MARGARET H. HAMILTON              DATE:  28 MAR 69
#             M.H.HAMILTON, COLOSSUS PROGRAMMING LEADER
#             APOLLO GUIDANCE AND NAVIGATION

La maschera contiene le informazioni generali circa la descrizione del software, alcune indicazioni sulla struttura, il team di sviluppo e la storicità del sorgente.

  • file  ASSEMBLY_AND_OPERATION_INFORMATION.agc (Colossus 2A) contiene la suddivisione logica in moduli funzionali del software con le pagine di rimando nel caso di una ricerca veloce all’interno dello stesso. Un file analogo è presente anche per il Luminary.
  • file ASSEMBLY_AND_OPERATION_INFORMATION.agc elenca i nomi (NOUNS) e verbi (VERBS) che l’AGC era in grado di processare. L’AGC infatti era in grado di accettare ed interpretare i comandi impartiti dagli astronauti interagendo con l’interfaccia DSKY secondo la sintassi:

<VERB> <NOUN>

Sia VERB che NOUN sono stringhe identificate da un codice univoco a due cifre. Ad ogni codice viene associato un comando (VERB) seguito (eventualmente) da un parametro specifico di quel comando (NOUN).

# NORMAL NOUNS                             COMPONENTS   SCALE AND DECIMAL POINT         RESTRICTIONS

# 00    NOT IN USE
# 01    SPECIFY MACHINE ADDRESS (FRACTIONAL)    3COMP   .XXXXX FOR EACH
# 02    SPECIFY MACHINE ADDRESS (WHOLE)         3COMP   XXXXX. FOR EACH
# 03    SPECIFY MACHINE ADDRESS (DEGREES)       3COMP   XXX.XX DEG FOR EACH

Più in basso c’è l’elenco dei verbi:

# REGULAR VERBS

# 00 NOT IN USE
# 01 DISPLAY OCTAL COMP 1 IN R1
# 02 DISPLAY OCTAL COMP 2 IN R1
# 03 DISPLAY OCTAL COMP 3 IN R1
# 04 DISPLAY OCTAL COMP 1,2 IN R1,R2

All’interno del progetto i seguenti moduli software sono particolarmente importanti:

  • BURN_BABY_BURN—MASTER_IGNITION_ROUTINE.agc esso contiene la sezione incaricata di inizializzare e controllare l’accensione del motore per la gestione dell’APS (programm P42), DPS (programma P40), PDI (programma P63) a l’ascesa dalla superficie lunare del LM (programma P12).
  • ALARM_AND_ABORT.agc contiene le routine di gestione degli errori (P00DOO, BAILOUT)

Lo screenshot seguente invece è estratto dal modulo LUNAR_LANDING.agc (Luminary 1A):

P63SPOT3        CA      BIT6            # IS THE LR ANTENNA IN POSITION 1 YET
                EXTEND
                RAND    CHAN33
                EXTEND
                BZF     P63SPOT4        # BRANCH IF ANTENNA ALREADY IN POSITION 1

                CAF     CODE500         # ASTRONAUT:    PLEASE CRANK THE
                TC      BANKCALL        #               SILLY THING AROUND
                CADR    GOPERF1
                TCF     GOTOPOOH        # TERMINATE
                TCF     P63SPOT3        # PROCEED       SEE IF HÈS LYING
P63SPOT4        TC      BANKCALL        # ENTER         INITIALIZE LANDING RADAR
                CADR    SETPOS1

                TC      POSTJUMP        # OFF TO SEE THE WIZARD...
                CADR    BURNBABY

Esso esegue il controllo della lettura del Landing Radar (LR) per l’allunaggio. L’algoritmo implementato è il seguente:

  1. Controlla se il radar è in posizione leggendo lo stato dal bit 6 del canale I/O33 dove viene memorizzato lo stato del radar.
    • In caso affermativo salta alla locazione P63SPOT4 per l’inizializzazione
    • altrimenti lancia la routine GOPERF1 per visualizzare sul DSKY il messaggio il cui valore è indirizzato dalla costante CODE500
      • Se l’astronauta digita il comando “TERMINATE”, trasferisci il controllo a P00 (stato di idle, in attesa di altri comandi) che si trova nel modulo FRESH_START_AND_RESTART.agc
      • Se digita il comando “PROCEED” torna al punto 1 e rileggi lo stato del radar.
  2. Esegui la routine SETPOS1 per inizializzare il LR, la routine POSTJUMP, e fai partire il motore del LM per iniziare la discesa (BURNBABY).

Un’ultima sezione interessante da analizzare riguarda la routine di calcolo delle funzioni trigonometriche. Per muoversi nello spazio l’uso delle funzioni trascendenti quali seno e coseno (così come il calcolo matriciale) sono fondamentali per l’implementazione degli algoritmi di navigazione. Qui si può trovare l’algoritmo implementato da Margaret Hamilton datato Marzo 1969 usato sia nel CM che nel LM e per comodità riportato anche qui sotto.

# SINGLE PRECISION SINE AND COSINE

		COUNT*	$$/INTER
SPCOS		AD	HALF		# ARGUMENTS SCALED AT PI
SPSIN		TS	TEMK
		TCF	SPT
		CS	TEMK
SPT		DOUBLE
		TS	TEMK
		TCF	POLLEY
		XCH	TEMK
		INDEX	TEMK
		AD 	LIMITS
		COM
		AD	TEMK
		TS	TEMK
		TCF	POLLEY
		TCF	ARG90
POLLEY		EXTEND
		MP	TEMK
		TS	SQ
		EXTEND
		MP	C5/2
		AD	C3/2
		EXTEND
		MP	SQ
		AD	C1/2
		EXTEND
		MP	TEMK
		DDOUBL
		TS	TEMK
		TC	Q
ARG90		INDEX	A
		CS	LIMITS
		TC	Q		# RESULT SCALED AT 1.

La routine (punto di ingresso SPCOS) calcola cos(\pi x) sfruttando l’equivalenza:

cos(\pi x)=sin(\pi (x + \frac{1}{2}))

A tal scopo la funzione somma \frac{1}{2} al valore iniziale x (nel registro A) quindi passa il controllo alla funzione SPSIN per il calcolo della funzione seno. Viene salvato il contenuto nella locazione temporanea TEMK per utilizzarlo in seguito nel calcolo del polinomio.

SINGLE PRECISION SUBROUTINE TEMPORARIES (3D)               
                # SPSIN, SPCOS, SPROOT VARIABLES.
                # DO NOT SHARE.  THESE ARE USED BY DAPS IN INTERRUPT
                # AND CURRENTLY ARE NOT PROTECTED.  IF OTHER USERS
                # MATERIALIZE, THEN THIS CAN BE CHANGED.
HALFY   ERASE
ROOTRET ERASE
SQRARG  ERASE
TEMK    EQUALS HALFY

Viene raddoppiato (DOUBLE) il suo valore (y_{a}) e chiamata la routine POLLEY tramite l’istruzione TCF. Lo scopo di POLLEY è calcolare y_{b}:

\begin{cases} y = x + \frac{1}{2} \\ y_{a} = 2 y  \\ y_{b} = \frac{1}{2} sin (\frac{\pi}{2} y_{a})  \end{cases}

tramite lo sviluppo in serie polinomiale di Taylor al quinto ordine (tre coefficienti).

Il blocco di codice racchiuso in SPT calcola:

y^{'} = \frac{1}{2} sin (\frac{\pi}{2} x) \approx 0.7853134 x - 0.3216147 x^{3} + 0.0363551 x^{5}
Confronto fra la funzione seno e con la stessa funzione ottenuta con lo sviluppo in serie di Taylor con tre coefficienti.
Per un’analisi dettagliata vedere: https://fermatslibrary.com/s/apollo-11-implementation-of-trigonometric-functions
Fonte: https://www.desmos.com/calculator/fmnu5rs6d6

I coefficienti di Taylor:

\begin{cases} C_{1} = 0.7853134  \\ C_{3}=−0.3216147 \\ C_{5}=0.0363551 \end{cases}

I coefficienti sono definiti nel codice nel seguente file: FIXED_FIXED_CONSTANT_POOL.agc

C1/2 DEC .7853134 # (OCTAL 31103)
…
C5/2 DEC .0363551 # (OCTAL 01124)
…
C3/2 DEC -.3216147 # (OCTAL 65552)

Essi non sono uguali a quelli che si otterrebbero con lo sviluppo in serie, tuttavia sono molto simili; questo perché gli ingegneri hanno ottimizzato i loro valori allo scopo di minimizzare l’errore di approssimazione nell’intervallo di utilizzo della funzione sul campo -1\leq x\leq 1.

Al termine di POLLEY viene nuovamente trasferito il controllo al programma chiamante ed il flusso di controllo procede con la chiamata alla routine ARG90, si sottrae LIMITS e si salva il risultato in virgola fissa, prima di ritornare il controllo al programma chiamante (TC Q).

Bibliografia

Per una descrizione più approfondita del codice di Margaret Hamilton, fare riferimento ai seguenti link in cui viene spiegato in maniera molto precisa e dettagliata.

Glossario istruzioni assembler

  • L’istruzione TCF lavora solo con indirizzi fissi e carica nel registro Z l’operando passato come parametro quindi trasferisce il controllo del programma alla locazione specificata dall’operando.
  • L’istruzione TC serve per impostare l’indirizzo di ritorno da una subroutine.
  • L’istruzione MP effettua la moltiplicazione (sempre in doppia precisione) con la parte alta in A e la parte bassa nel registro L. Il valore originale del moltiplicando viene perso.
  • L’istruzione XCH scambia il contenuto di A con il contenuto della locazione di memoria volatile specificata come parametro.
  • L’istruzione TS trasferisce il valore di A nella locazione di memoria volatile specificata come parametro.
  • L’istruzione CS azzera e sottrae l’operando passato come parametro al registro A.
  • L’istruzione DOUBLE raddoppia il contenuto di A.
  • Le istruzioni INDEX/EXTEND sono usate per l’accesso a tabelle/array tramite l’indicizzazione. Rappresenta un offset per l’accesso in memoria di un elemento.

Il software dell’Apollo

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’allunaggio1.

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 assembler2 (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

%d blogger hanno fatto clic su Mi Piace per questo: