Processo di sviluppo utilizzato per il codice sulle missioni Apollo 11?

C'era un bel documentario che sto cercando di inseguire su John 'Jack' Garman ha dovuto "inventare" un "sistema operativo multiprogrammante programmato con priorità". Questo potrebbe essere stato collegato al modulo di lander però. La storia era che quando si sbarca il lander, è meglio dare priorità alla guida, perché altre cose, come la temperatura in cabina per i successivi 15 secondi, non importava davvero se si fosse schiantato e bruciato. Al primo colpo hanno sovraccaricato il computer e gli allarmi hanno iniziato a verificarsi perché alcune subroutine non venivano eseguite. C'erano troppi carichi, ma grazie al concetto di priorità, che Garman aveva previsto e integrato perché pensava che fosse una buona idea, le routine a bassa priorità non impantanavano la routine di atterraggio con priorità più alta.

Guardando il documentario in quel momento, mi ha colpito il modo in cui è stato come eseguire un importante refactoring sul codice senza dire alla direzione e quasi essere stato licenziato perché eri in ritardo su ciò a cui dovevi lavorare. In questo caso, tuttavia, il refactoring è venuto alla luce quando è stato esaminato il motivo degli allarmi. (E il management era ancora incazzato!: -)

Alcuni link:

No, un "errore di lista di controllo" non ha quasi fatto deragliare il primo sbarco sulla luna

TALES DEL LUNAR COMPUTER DEL MODULO DI GUIDA

Come l'hanno costruito: il software di Apollo 11

Progetto di storia orale del Centro spaziale Johnson Johnson  Trascrizione della storia orale modificata

Breve storia del programma Apollo della NASA Estratto: Cinque minuti dopo la discesa, e 1.800 m sopra la superficie della Luna, il computer di navigazione e guida LM ha prodotto il primo di numerosi allarmi di programma "1202" e "1201" inattesi. Il L'ingegnere informatico del Mission Control Center di Houston, Jack Garman, ha detto all'ufficiale di guida Steve Bales che è stato sicuro di continuare la discesa. Questi allarmi erano indicazioni di "overflow dell'esecutivo", il che significa che il computer di orientamento non poteva completare tutti i suoi compiti in tempo reale e ha dovuto rimandarne alcuni.

Ricordando il "salto gigante" Estratto: sapevamo cosa fosse e che non dovesse accadere. Ma avevamo progettato un sistema che tentava di recuperare da qualsiasi condizione di sovraccarico. Quindi ricordo di aver sentito [l'ingegnere informatico della NASA] Jack Garman che gridava: "Vai, vai!" E su sono andati. Poi ascoltammo Neil mentre volavano sul LEM e cercando di trovare un buon posto per il touchdown. La nostra nuova preoccupazione era la mancanza di carburante rimanente. Ma alla fine abbiamo sentito l'avviso di contatto e poi "L'Aquila è atterrato".

Intervista a Jack Garman

EDIT: Forse questo era il documentario: Apollo 11: The Untold Story (2006)

Cast: John R. Garman ...
Se stesso - Apollo 11 Computer Engineer (con il nome Jack Garman)

(Tra gli altri).

Aggiornamento: Un hacker del Sud Africa Salvataggio del primo computer NASA nello spazio

Se ho capito bene, il processo di sviluppo è stato revisione e sperimentazione tra pari.

Il team era composto da persone come "Math Doctors" - persone estremamente dedite, intelligenti, appassionate, attente ai dettagli le cui vite erano dedicate al loro lavoro. Quindi quando parlo di peer review, intendo molte revisioni tra pari nel corso di molti mesi (più di un anno).

Questi sviluppatori "gestivano le simulazioni nelle loro teste", "eseguivano il debug del software su carta" e lavoravano in gruppi con molti sviluppatori che guardavano lo stesso codice più e più volte fino a quando non erano convinti che fosse corretto. C'erano più squadre - ciascuna che lavorava su una parte del tutto.

Il mio professore di metodi numerici presso la Ohio State University (primavera del '96) ha scritto il codice che decise quando dare il via a un palco del razzo di lancio. Ha descritto che la stampa è la dimensione della rubrica (quindi, forse da 2,5 a 3,5 pollici di spessore di carta da 8,5 x 11 pollici - non ha descritto la dimensione del carattere) del codice Fortran.

Quando convinti, lanciarono un missile senza pilota (i razzi tecnicamente non hanno giroscopi) con una radio a bordo che emetteva un segnale acustico a intervalli regolari. Hanno ascoltato i segnali acustici fino al punto in cui si aspettavano che la radio avesse un impatto sulla luna (schiantarsi contro di essa e distruggere se stessa) e smettere di emettere un segnale acustico. Sapevano che se l'avessero perso, la radio avrebbe continuato a suonare a lungo oltre il tempo di impatto calcolato. L'impatto si è verificato 15 secondi dopo il tempo calcolato.

Questa storia incredibilmente aneddotica sono i miei ricordi di una visita in ufficio con il dottore. Era molto vecchio, ed è stato tanto tempo fa. Questo è il mio miglior ricordo.

L'AGC è controllato con verbi e nomi

Il software di comando di Apollo non è scritto in alcuna sintassi che gli utenti riconoscono oggi. Gli astronauti immettono i comandi numericamente, con ciascun numero di due cifre che rappresenta un verbo o un nome. Il verbo ha descritto l'azione da eseguire e il nome ha specificato i dati da influenzare dall'azione del verbo.

Gli astronauti odiavano il verbo e l'impostazione del nome

Ramón Alonso, uno degli sviluppatori di hardware originali di AGC, ha detto che l'interfaccia è stata inventata per impressionare i visitatori del loro laboratorio, ma si è presa cura dei voli quando nessuno ha sviluppato un'interfaccia migliore. I critici hanno detto che non era "scientifico" e che i primi astronauti, tutti piloti di jet d'élite, preferivano quadranti e interruttori, simili a un pannello di controllo dell'aereo.

"The AGC was very slow, but very reliable and very small for that time in the history of digital computers. It was the earliest to use integrated circuits."

Il software così come è stato progettato è stato costruito fondamentalmente da zero dal MIT.

Puoi scaricare e installare il programma di emulazione di Computer Guidance Apollo sul tuo personal computer, nessun problema. Ecco come appare su Mac OS X.

Come quasi tutti gli altri progetti software, è stato eseguito con scadenze aggressive e pressione di qualità. Fortunatamente un grande archivio di materiale dal project manager del software Howard W. "Bill" Tindall, Jr. è disponibile qui .

Se si campionano i promemoria, è possibile ottenere un ottimo senso del normale conflitto tra tempo, funzionalità e difetti. Vale la pena notare che lo sviluppo procedette per un certo numero di anni come il resto del progetto.

Design of the system began in the second quarter of 1961, and NASA installed a Block I version in a spacecraft on September 22, 1965. Release of the original software (named CORONA) was in January 1966, with the first flight on August 25, 1966. Less than 3 years after that, designers achieved the final program objective (http://history.nasa.gov/computers/Ch2-5.html)

Non riesco a trovare riferimenti specifici su come è stato creato il software, ma data la data posso solo supporre che gran parte di esso sia stata fatta su carta e penna, con "simulazioni" fatte manualmente. Sembra che ci fosse un sistema per caricare i programmi nell'AGC con schede perforate, presumibilmente per test "rapidi" a terra senza la necessità di fabbricare memorie di corda.