Categoria: Software

Il codice sorgente dell’AGC

By articolidiastronomia on 03/04/2022

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:

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.
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}

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

The Apollo Guidance Computer Architecture and Operation, Frank O’Brien – Springer
https://www.pluralsight.com/courses/moon-landing-apollo-11

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

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

Moonshot computing, Brian Hayes – American Scientist
https://www.pluralsight.com/courses/moon-landing-apollo-11
https://abcnews.go.com/Technology/apollo-11s-source-code-tons-easter-eggs-including/story?id=40515222
Some funny things happened on the way to the Moon, Richard H. Battin – MIT Massachusetts
The Apollo Guidance Computer Architecture and Operation, Frank O’Brien – Springer

Interazione Uomo-Macchina nel progetto Apollo

By articolidiastronomia on 06/12/2021

Gli astronauti selezionati dalla NASA erano tutti piloti esperti di jet militari altamente qualificati che erano abituati a gestire le situazioni critiche in volo in prima persona, tuttavia con la corsa allo spazio, affidare ogni operazione solo ai piloti poteva essere molto rischioso e mettere a repentaglio la vita stessa degli astronauti. Per questo motivo la presenza di un rudimentale computer a bordo era già stata prevista ed implementata per il programma X-15, in modo da aiutare il pilota nell’eseguire i calcoli o gestire le situazioni di emergenza. Con l’aumentare del carico e della complessità del lavoro da svolgere in vista dell’obiettivo Luna, la discussione si fece molto accesa e vide nascere due scuole di pensiero distinte divise fra il controllo manuale ed il controllo automatizzato della capsula.

X15

Erano i primi aerorazzi sganciati in volo da un bombardiere B52 in grado di raggiungere una quota fino a 350.000 piedi (circa 105 Km) per poi atterrare nel deserto lungo una traiettoria balistica

La prima opzione era quella preferita dalla maggior parte degli astronauti, in quanto venivano dal mondo dell’areonautica dove erano abituati a “tenere-in-mano” l’aereo, ovvero a governare il veivolo agendo direttamente con le proprie forze sugli attuatori. La seconda opzione invece vedeva tra i suoi maggiori sostenitori i progettisti ed ingegneri. Essi erano ben consapevoli che pilotare una navicella spaziale è tutto un’altra cosa: ci sono tante operazioni che devono essere eseguite alla precisione, in sequenza ed in un intervallo di tempo brevissimo e qualsiasi cosa può non funzionare tanto che nemmeno l’astronauta più preparato con ottimi riflessi sarebbe stato in grado di agire per tempo. Quest’ultima opzione non piaceva agli astronauti perché rischiava di relegare il loro ruolo a spettatori passivi.

Dicotomia Uomo-Macchina raffigurata in una vignetta dell’epoca.
Gli astronauti sono spettatori passivi durante il viaggio verso la Luna o possiedono un ruolo decisionale attivo?

Come includere quindi gli astronauti in questa nuova gestione?

Spettatori passivi o persone con un ruolo decisionale?

Allo scopo di garantire la maggior sicurezza possibile per i piloti si decise che essi avrebbero dovuto acquisire un insieme di competenze non legate esclusivamente al volo, ma anche al funzionamento della strumentazione e imparare come quest’ultima si interfacciava con gli attuatori del velivolo per agire di conseguenza in caso di emergenza.

Fonte immagini a sinistra:

Charles Stark Draper Laboratory Archives Photo 24861 Smithsonian Museum
Charles Stark Draper Laboratory Archives Photo 24860 Smithsonian Museum

Elaboratore e astronauti avrebbero dovuto quindi agire in concertazione in tutte le fasi di volo per integrarsi con i sistemi di avionica dell’Apollo

A tale scopo la suddivisione delle operazioni fra uomo e macchina venne rivista: gli astronauti avevano il compito di monitorare le operazioni di volo ed in orbita erano parte attivi del processo decisionale insieme al sistema di controllo: potevano in ogni caso interagire, integrare o correggere le direttive impartite dal computer, così come sostituirsi ai processi automatici dell’elaboratore e prendere il comando della navicella all’occorrenza in ogni parte del volo.

Questa scuola di pensiero venne soprannominata “man-in-the-loop”, e fu quella che venne effettivamente usata in tutte le missioni Apollo, ove tutti gli allunaggi avvennero con i sistemi di controllo attivi e gli astronauti supervisori finali in grado di inserirsi all’interno del sistema di controllo (come effettivamente fu).

L’introduzione del computer significava inoltre che per le missioni lunari non erano più sufficienti gli ingegneri meccanici, ma si affiancavano anche gli ingegneri elettronici: una volta identificato il ruolo degli astronauti era necessario passare alla fase di progettazione e costruzione dei computer di bordo. Come procedere? Quando nel 1958 la NASA creò lo Space Task Group sotto la direzione di Robert Gilruth venne nominato Max Faget come ingegnere responsabile del progetto della Mercury, Gemini ed Apollo, i quali vennero subito influenzati dal controllo elettronico con complessità crescente.

Timeline dei progetti X15, Mercury, Gemini ed Apollo: i progetti sono stati sviluppati in parallelo.
Ogni volta che venivano consolidate le conoscenze del progetto in corso queste ultime venivano utilizzate nel progetto seguente. Diagramma dell’autore

La Mercury era una capsula costruita dalla McDonnel-Douglas, con un sistema di controllo progettato dalla Honeywell Regulator Company. Durante le normali operazioni la capsula lavorava in modalità automatica e solo in caso di problemi del sistema primario il pilota avrebbe assunto il controllo della situazione con due sistemi di controllo separati. L’astronauta non aveva alcun controllo sull’orbita, poteva solo cambiarne l’assetto tranne durante l’operazione di rientro ove la capsula si orientava automaticamente nella posizione corretta con lo scudo termico verso il basso.

Per il progetto Gemini invece, che includeva operazioni più complesse (rendezvous, docking ed EVA), vennero utilizzati computer sviluppati dalla IBM (che già collaborava con la marina negli anni ‘50) dal peso di 27 Kg avente 7 programmi precaricati: i minimi necessari e previsti per lo scopo della missione.

Per il progetto Apollo, trattandosi di un sistema molto più complesso dei precedenti, la capacità di calcolo degli elaboratori venne sfruttata al massimo al fine di migliorare la stabilità della capsula, intesa come secondo requisito di base fondamentale per una missione lunare. In particolare l’elaboratore doveva gestire:

partenza (come sistema di back up del terzo stadio del Saturn V)
il viaggio verso la Luna
l’allunaggio
il rendezvous
inserimento in orbita terrestre
l’ammaraggio.

La stabilità viene ottenuta tramite un sistema di controllo basato su un sistemi ad anello chiuso come quello in figura a sinistra.
Il sistema confronta l’ingresso di riferimento (velocità, smorzatore d’imbardata, …) con quello reale letto dai sensori (uscita controllata). La differenza, ovvero il segnale di attuazione (o errore) viene applicato ai segnali di controllo del sistema.

Queste funzionalità dovevano essere racchiuse in una serie di computer (AGC Apollo Guidance Computer) che occupasse uno spazio modesto, consumasse poca energia e funzionasse per circa due settimane di viaggio: il progetto iniziò nel 1962 a partire da un prototipo basato su logica a transistor che avrebbe dovuto essere usato per una futura missione su Marte.

AGC

Con il termine AGC si intende genericamente il computer della capsula Apollo; in realtà vennero progettati due versioni: uno per il modulo di comando (CGC) e uno per il LM (LGC). Entrambi condividevano parecchie funzionalità di libreria, oltre ovviamente a funzionalità specifiche del sistema. Il LM inoltre includeva anche un computer di backup AGS usato in caso di abort della missione e come backup del LGC. Un altro computer era presente nell’anello di raccordo del primo stadio del Saturn V per gestire la piattaforma inerziale e le fasi di volo del primo stadio.

Il computer aveva le seguenti caratteristiche:

Dimensioni di un piede cubico (circa 28 dm³). Una dimensione molto ridotta, tenendo presente che negli anni ’60 i computer erano molto ingombranti, consumavano molta corrente e occupavano interi edifici universitari.
Programmabile (con una modesta capacità di calcolo)
Un microprocessore in grado di gestire interrupt esterni a priorità per gestione di eventi real time per la piattaforma inerziale, i propulsori SPS e RCS.
Un watchdog (NIGHT WATCHMAN) per consentire al microprocessore di uscire dalle condizioni di stallo
DAC/ADC per comunicare con le interfacce analogiche esterne

Sebbene fosse chiamato computer, in realtà era un sistema embedded basato su microprocessore, una memoria RAM/ROM e un sistema di interfacciamento con i sensori ed attuatori di bordo. Oggi un sistema siffatto si chiama microcontrollore.

Vista al microscopio di una porta NOR usata per l’Apollo.
Fonte: https://airandspace.si.edu/stories/editorial/apollo-guidance-computer-and-first-silicon-chips

La prima versione del AGC nota come Block I venne rilasciata nel 1963: si basava su un solo tipo di circuito integrato (una porta NOR a tre ingressi) esteso anche ai sensori di interfacciamento in modo da rendere il sistema più modulare, mentre il sistema di navigazione rilasciò la sua parte nel settembre dello stesso anno. Garantire l’affidabilità di un sistema che si basava su una tecnologia ancora in stadio embrionale (come quello dei circuiti integrati) era un problema che assillava gli ingegneri progettisti e la NASA stessa, pertanto si decise di produrre componenti in serie tutti uguali per enormi volumi in modo da poter semplificare i test di qualità del prodotto.

La Fairchild (l’azienda appaltatrice) decise di lavorare in lotti: ogni circuito integrato veniva esaminato, sottoposto a stress meccanici e immerso in una soluzione di freon per verificare eventuali perdite. Piccole variazioni di peso superiori a 5 mg indicava che parte del liquido era entrato all’interno dell’integrato, e di conseguenza tutto il lotto veniva scartato. Altri test di produzione includevano: test sulle vibrazioni, di escursioni termiche, shock, umidità, rumore elettronico e variazioni di salinità.

Schema circuitale della porta NOR a due ingressi.
Qualsiasi funzione logica può essere implementata con porte NOR perché é una porta universale.

La NASA affidò ai laboratori IL del MIT il sistema principale di navigazione (IMU), il quale era già stato coinvolto nel passato nel sistema di guida di missili Polaris. Il gruppo di lavoro, sotto la guida di Charles Draper, progettò un sistema di navigazione (IMU) usato per mantenere l’assetto, posizione e velocità (previa una procedura di allineamento).

tre accelerometri per identificare tutte le forze agenti sulla capsula in movimento.
tre giroscopi di precisione per il controllo dell’assetto. L’uso dei giroscopi consentiva di tenere gli accelerometri in una direzione costante nel loro frame di riferimento indipendentemente dall’orientazione della capsula: in modo da dare al CSM la capacità di navigare senza un sistema di riferimento esterno.

L’Apollo montava tre giunti cardanici per mantenere in sospensione i giroscopi, comunque insufficienti per evitare il “gimbal lock”, ovvero una situazione per cui la piattaforma perdeva una dimensione di riferimento e quindi non poteva fornire una misura corretta dell’assetto della capsula. Il quarto giunto non venne installato sia per motivi di spazio e poi perché tutte le manovre erano progettate per essere effettuate in due dimensioni. Il computer aveva una procedura che periodicamente controllava il suo stato e avvisava in tempo gli astronauti in caso fosse vicino alla situazione critica, ma nonostante questo sia nella missione Apollo 11 che Apollo 13 si verificarono situazioni di rischio. A queste caratteristiche IL aggiunse:

un telescopio e un sestante spaziale a 28 ingrandimenti: per il controllo manuale ed eventuale correzione di rotta. Il sestante aveva due linee di vista: una fissa o LLOS (la linea dell’orizzonte) e una mobile o SLOS (linea stellare). Per garantire maggior precisione, il sistema era solidale con la capsula Apollo e IMU stessa, come un banco ottico. L’astronauta puntava la linea dell’orizzonte verso il punto di riferimento e la linea della stella in direzione di un altro oggetto e muoveva il sestante finché le due immagini non si sovrapponevano: alla fine l’astronauta premeva un pulsante ed il computer registrava l’angolo di vista. La differenza fra la posizione reale e quella stimata dal computer serviva allo stesso per modificare il suo allineamento.
una console per interagire con il computer ed elettronica di supporto

Il banco di prova del AGC Block I avvenne con i primi test LEO sotto la guida di Robert Shea: questa versione non poteva navigare verso la Luna, pertanto tutte le nuove caratteristiche vennero incorporate nella versione successiva: AGC Block II.

I problemi di interfacciamento con le apparecchiature elettroniche non mancarono comunque: nel Maggio 1963, durante l’ultimo volo della Mercury Gordon Cooper ebbe un problema con il sistema di controllo: dell’urina fuoriuscita dal sistema di raccolta aveva corroso la circuiteria elettronica; questo portò la NASA a sigillare ermeticamente tutta l’elettronica.

La capsula per motivi di sicurezza veniva guidata da Terra grazie all’aiuto di tre stazioni: Spagna, Australia e California che dialogavano con il trasponder di bordo dell’Apollo: negli anni ‘60 la precisione degli orologi atomici consentiva alla NASA un ottimo livello di approssimazione. A partire dal ritardo di trasmissione e dall’effetto Doppler la NASA poteva calcolare la posizione dell’Apollo con un errore di 10 metri e la velocità con un errore di 0,5 m/s (il radar consente di ricostruire l’orbita di un corpo celeste ma non il suo assetto). In ogni caso il computer era essenziale quando transitava lungo la faccia nascosta della Luna, causa l’assenza di segnale da Terra.

Tidbinbilla (Australia): parabola del sistema DSN della NASA per il tracking dell’Apollo
Fonte: https://www.space.com/how-nasa-tracked-apollo-11-communications.html

*Core Rope Memory (ROM)*	6 banchi @ 6144 Word
*Magnetic Core Memory (RAM)*	2 KWord
*8 istruzioni base + EXTEND + INTERPRETER*	*⋍ 50 istruzioni*
*Clock*	2048 KHz + altri prescaler
*Peso*	70 libbre (circa 31 Kg)
*Consumo*	70W – 28V DC + altri convertitori DC/DC
*Diodi, transistor, resistenze*
*DSKY*	Display e tastiera

Tabella caratteristiche AGC Block II

Il computer di bordo era un sistema fly-by-wire: faceva da interfaccia e mediava tutte le operazioni di volo. Il software doveva imparare ad interagire con i sottosistemi della capsula, reagire ai cambiamenti esterni e formare un processo decisionale adatto, in ogni livello. Il MIT produsse un prototipo a novembre 1965 per essere poi consegnato alla NASA nel luglio 1966.

A lato le caratteristiche dell’AGC Block II.

2KWord son diversi da 4Kbytes

Dal punto di vista implementativo 2 bytes sono diversi da 1 Word. Infatti un computer che deve processare un byte ma e’ stato progettato per lavorare in Word significa che la CPU deve effettuare operazioni di post processing (mascheramento e shift-register) quindi impiegare ulteriori tempi aggiuntivi di elaborazione (cicli di fetch).

Bibliografia