Apollo 11 och kvinnan bakom koden

Den 20 juli 1969 när månlandaren Eagle för Apollo 11 var på väg ner mot månens yta började dess styrprogram Luminary att bete sig oroväckande genom att skicka ut larmen 1201 och 1202 omväxlande på grund av för många signaler från sensorerna, såsom rendezvous-radarn. För en kort stund verkade det som landningen skulle misslyckas. Men Luminary gjorde det den var designad för, genom att prioritera bort mindre viktiga signaler och fokusera på de för stunden mest kritiska uppgifterna.

Det är denna detalj som gör Apollo 11:s styrprogram så fascinerande. Det stora teknikhistoriska dramat ligger inte bara i raketerna, utan i att själva landningen bars av mjukvara som redan 1969 uppvisade drag av det vi i dag skulle kalla feltolerant systemdesign. Under överlast släppte datorn mindre viktiga uppgifter, återstartade och fortsatte med det som måste överleva. Med moderna ord kan man kalla det Graceful Degradation Under Load, Load Shedding and Priority Inversion och genomtänkta Resource Pool Exhaustion Strategies. Med 1969 års ord kallades delar av samma värld för ALARM, BAILOUT och POODOO.

I centrum för detta står Margaret Hamilton och hennes team vid MIT Instrumentation Laboratory. Hennes insats kan knappast reduceras till att hon "var med och skrev kod". Hon tillhörde den krets som formade hur programvara skulle bete sig när verkligheten avvek från planen. Apollo 11 visar därmed inte bara att människan kunde nå månen, utan att stor ingenjörskonst också består i att få ett system att fortsätta fungera när allt håller på att gå fel.

Margaret Hamiltons "what if?"

Det finns en anekdot om Margaret Hamilton som säger mer om hennes ingenjörssyn än många hyllningstal. På Google-bloggen om hyllningen till henne 2019 berättas hur hon ibland tog med sig sin dotter Lauren till jobbet. Under en pågående simulering hände det en gång att dottern tryckte på en knapp som startade ett pre-boot-program, trots att den simulerade farkosten redan var i luften, d.v.s. hade bootat upp. Resultatet blev att systemet kraschade.

Bilden visar Hamilton inuti simulatorn.

Hamiltons första reflex var inte att skälla på barnet, utan att ställa sig en fråga: vad händer om en astronaut gör exakt samma sak under en verklig mission?

Vissa ingenjörer tänker först på den normala körningen, den idealiska sekvensen, det fall där användaren gör rätt. Hamilton tänkte på avvikelsen, på det osannolika men möjliga, på operatörsfelet som inträffar just när systemet redan är pressat. Den hållningen kom att prägla hennes arbete med AGC (Apollo Guidance Computer).

Det är också därför hon i efterhand framstår som så modern. Hennes "what if?" är i grunden samma fråga som ligger bakom all seriös fault tolerance design. Vad händer om någon trycker fel? Vad händer om lasten blir högre än väntat? Vad händer om en del av systemet fortfarande måste leva vidare trots att resten måste städas bort? I AGC-koden får denna hållning konkreta namn med kulturella konnotationer.

Vi återfinner WHIMPER som innebär att systemet gör en kontrollerad omstart, vilket var det som räddade situationen under nedstigningen. Ordet är en medveten litterär referens till den brittisk-amerikanska nobelpristagaren och poeten T. S. Eliot och specifikt slutraden i hans dikt The Hollow Men:

“Not with a bang but a whimper.”

När AGC tvingas starta om efter ett fel, gör den det inte “med en smäll” (dvs. inte genom att krascha), utan lugnt, kontrollerat och nästan antiklimatiskt — med en “whimper”.

Vi finner också uttrycket CURTAINS som emanerar från teatervärlden och betyder "ridå, spelet är över" - och om det omsätts till datortermer, betyder det att nu är det kört. I detta allvarliga läge startar hela systemet om. I UNIX kallas detta för panic och innebär att OS startar om.

Hamilton har senare blivit en ikon, inte minst genom den berömda bilden där hon står bredvid en tornlik utskrift av programkoden. Men hennes storhet ligger inte i symboliken utan i blicken för systembeteende. Hon såg, tidigt och klart, att robust mjukvara inte bara handlar om att få rätt svar när allt går rätt, utan om att göra fel på rätt sätt när något oväntat inträffar. Det är också Hamilton som myntat ingenjörstiteln "Software Engineer".

Bilden visar Hamilton tillsammans med en utskriven version av hela styrprogrammet

När datorn blev överlastad

Detta tänkesätt sattes på prov under själva månlandningen. Larmen 1201 och 1202 uppstod därför att AGC:n under nedstigningen blev överlastad. Den fick mer arbete än den hann med. Att beskriva det som att "datorn höll på att dö" är missvisande. Det korrekta är nästan elegantare: den gjorde precis det den var byggd för att göra.

AGC:n var konstruerad för att prioritera. När resurserna inte räckte till för allt, valde den inte panik utan ordning. Det mindre viktiga fick falla bort så att det viktigaste kunde fortsätta. Man kan beskriva detta som load shedding, alltså att systemet kastar av sig last för att rädda kärnfunktionerna. Det är en princip som i dag känns hemma i molnplattformar och realtidssystem, men här finns den i ett 60-talssystem på väg mot månen. I denna värld fanns också grader av misslyckande.

• ALARM - är just ett larm, ett tecken på att något måste uppmärksammas.
• BAILOUT - en abortväg som kan utlösas av en operator, med en känsla av att man kan ta sig ut ur en situation.
• POODOO - allvarligare fel som rensar systemtillståndet med MR.KLEAN.

Här blir också uttrycket Graceful Degradation Under Load användbart. Det låter som ett föredrag på en samtida arkitekturkonferens, men beskriver exakt vad som gjorde Apollo 11 möjlig. Under belastning degraderades systemet graciöst. Det stängde inte butiken. Det blev mindre komplett för att kunna förbli användbart. Hade styrprogrammet varit mindre genomtänkt kunde larmen ha utlöst ett avbrott. I stället gav de Mission Control i Houston och besättningen information nog för att förstå att datorn fortfarande hanterade de kritiska funktionerna.

Det är här Hamiltons arv går från teori till historia. Den kontrollerade återstarten under månlandningen var inte ett mirakel och inte tur. Den var ett resultat av att någon på förhand hade tagit frågan om det osannolika på allvar.

Det här designtänket att dela upp ett system i mindre delsystem och vid abnormala tillstånd starta om involverade delsystem kom också att influera Joe Armstrong när han vid Ellemtel/Ericsson i Älvsjö designade programspråket Erlang i slutet av 1980-talet.

Ett Erlang-program kan, lite slarvigt, uttryckas som en soppa av småprocesser som skickar asynkrona meddelanden mellan varandra. En grupp av processer bildar ett delsystem, som övervakas av en så kallad supervisor-process. Ett antal av dessa kan i sin tur övervakas av en annan supervisor-process, och så vidare. Denna designprincip kallas för "supervision hierarchy".

När ett abnormalt delsystemstillstånd inträffar i en process, skickar den en EXIT-signal till sin övervakande supervisor-process. Denna har då till uppgift att avgöra huruvida en eller alla processer i delsystemet ska startas om. Om den övervakande processen inte kan återställa sitt delsystem, kan den också skicka en EXIT-signal upp i övervakningshierarkin. I detta fall kan en större del av systemet startas om.

PINBALL, DSKY och människan i loopen

Den som vill förstå Apollo 11 som ett mjukvarusystem måste också se gränssnittet. Astronauterna talade inte direkt med någon osynlig abstraktion. De använde DSKY, Display and Keyboard, den kompakta enheten med knappar, numeriska displayer och lampor som i dag ser ut som en märklig blandning av kalkylator, avionik och altartavla. Smithsonian har ett bevarat exemplar som påminner om hur fysisk denna digitala värld faktiskt var.

Bilden visar DSKY och denna hanterades av programvaran PINBALL.
© Smithsonian Institution – Air and Space Museum

Den kod som drev interaktionen kallades PINBALL, vilket på svenska blir flipperspel. Namnet låter som ett skämt, och det var det också, men ett tekniskt informativt sådant. PINBALL var inte Houston, inte någon markdator, utan mjukvaran ombord som hanterade knapptryckningar, lampor, displayuppdatering, felindikeringar och verb/noun-logiken som astronauterna arbetade genom. Knapparna klickade och displayerna blinkade som på ett flipperspel. Det är svårt att tänka sig ett tydligare exempel på hur avancerad programvara alltid till sist möter människan via ett gränssnitt.

Och just där blir AGC-koden så ovanligt mänsklig. Den talar ibland nästan tillbaka. När man i listningarna stöter på uttryck som PLEASE CRANK THE SILLY THING AROUND förstår man att detta inte var en steril, opersonlig kodmassa. Det var en uppmaning till astronauterna att ompositionera månlandarens radarantenn. Bakom de kritiska rutinerna satt människor som arbetade under extrem press men fortfarande hade plats för ett torrt, nästan muttrande tonfall. I en modern kodbas skulle formuleringen sannolikt ha korrigerats bort i en code review. Här står den kvar och gör historien mer levande.

En kodbas med lärdom och humor

Det mest underhållande med AGC-koden är kanske att den samtidigt är djupt allvarlig och full av personlighet. Man behöver bara bläddra en kort stund i de bevarade listningarna för att märka att detta inte är en miljö där allt döpts till module_17 och handler_3. I länksamlingen sist i denna artikel hittar du länken till källkoden och kan bilda dig din egen uppfattning.

Vissa namn är raka och handfasta. BURN BABY BURN är huvudrutinen för tändningen av raketmotorn, ett namn som i sin lättsinnighet nästan känns otillbörligt i ett system där fel kunde bli fatala. Samtidigt säger just det något om miljön. Detta var ingenjörer som inte såg någon motsättning mellan rigorös matematik och svart humor. Så här ser inledningskoden ut i raketstyrningsrutinen hos månlandaren.

# BURN, BABY, BURN -- MASTER IGNITION ROUTINE

		BANK	36
		SETLOC	P40S
		BANK
		EBANK=	WHICH
		COUNT*	$$/P40

# THE MASTER IGNITION ROUTINE IS DESIGNED FOR USE BY THE FOLLOWING LEM PROGRAMS:  P12, P40, P42, P61, P63.
# IT PERFORMS ALL FUNCTIONS IMMEDIATELY ASSOCIATED WITH APS OR DPS IGNITION:  IN PARTICULAR, EVERYTHING LYING
# BETWEEN THE PRE-IGNITION TIME CHECK -- ARE WE WITHIN 45 SECONDS OF TIG? -- AND TIG + 26 SECONDS, WHEN DPS
# PROGRAMS THROTTLE UP.
    . . .
# THE MASTER IGNITION ROUTINE WAS CONCEIVED AND EXECUTED, AND (NOTA BENE) IS MAINTAINED BY ADLER AND EYLES.
#
# 		   HONI SOIT QUI MAL Y PENSE
#
#	***********************************************
#		TABLES FOR THE IGNITION ROUTINE
#	***********************************************
#
#			NOLI SE TANGERE

P12TABLE	VN	0674		# (0)
		TCF	ULLGNOT		# (1)
		TCF	COMFAIL3	# (2)
		TCF	GOCUTOFF	# (3)
		TCF	TASKOVER	# (4)
		TCF	P12SPOT		# (5)
		DEC	0		# (6)	NO ULLAGE
		EBANK=	WHICH
		2CADR	SERVEXIT	# (7)
    . . .

Uttrycket i början är lånat från den legendariske amerikanske radioprataren Magnificent Montague, som när han skulle till att spela en riktigt het poplåt utbrast "Burn, baby! Burn!". På svenska skulle vi kunnat ha hört något liknande från Clabbe (Claes af Geijerstam) - legendarisk svensk radiopratare för oss som har ålder inne.

Något längre ned ser vi två märkliga kommentarer, den första på medeltida franska och den andra på latin. Uttrycket HONI SOIT QUI MAL Y PENSE betyder ungefär "skam den som tänker illa därom". Frasen är en klassisk hedersmarkering som används för att avfärda misstänksamhet eller illvillig tolkning. I sin ursprungliga kontext betyder den ungefär: “Om du tror att detta är fel, är det du som har ett dåligt sinne.”

Några rader ned finns kommentaren på latin NOLI SE TANGERE som betyder ungefär “Rör mig inte”. I källkoden användes den som en tydlig varning till framtida utvecklare att inte röra en viss del av koden — i detta fall ignition tables, alltså tändtabellerna för motorerna.

Det senare kan läsas som en tidig pendang till den berömda UNIX-kommentaren "You are not expected to understand this." Det är inte fråga om ett direkt historiskt släktskap, men om samma tonfall: här finns kod som fungerar, kod som är ömtålig, och kod där författaren vänligt men bestämt avråder eftervärlden från att peta i den.

Sedan finns de mer burdusa eller lekfulla uttrycken. FLAGORGY låter som ett MIT-skämt om överdriven flagghantering, men innebar att alla boolska variabler initierades. NO ROOM IN THE INN ger resursbrist en biblisk klang. OFF TO SEE THE WIZARD lånar sin ton från The Wizard of Oz. ENEMA som på svenska betyder lavemang, visar att även en annars extremt disciplinerad kodmiljö kunde rymma en ganska kroppslig typ av internhumor. Och CCSHOLE är ett namn man knappast hade släppt igenom i dagens mer hygieniska utvecklingskultur, men just därför är det så intressant. Det påminner om att också den mest legendariska kodbas är skriven av människor, med allt vad det innebär av irritation, trötthet, esprit och skadeglädje.

Det vore dock ett misstag att se dessa namn som pynt. De fyller en viktig funktion i artikeln, eftersom de visar att Apollo-programmets mjukvara inte bara var tekniskt avancerad utan också kulturellt rik. Här möts klassisk bildning, ingenjörsdisciplin och internhumor i samma källkod. Kombinationen känns nästan omöjlig att konstruera i efterhand, och är därför desto mer övertygande som historiskt vittnesbörd.

Efterliv i månljus

I dag är Margaret Hamilton ett av de namn som oftast lyfts fram när mjukvarans historia ska berättas, och det med rätta. Hon har blivit symbol för en epok då programvara ännu inte ens hade fullt etablerad status som ingenjörsdisciplin. Linda Hall Library påminner om att hon inte bara arbetade i denna värld utan också bidrog till att ge den ett namn. Uttrycket "software engineering" var i hög grad något hon själv drev och försvarade, i en tid då många fortfarande såg mjukvara som något sekundärt i förhållande till hårdvaran.

När jag pluggade datateknik på KTH under 1980-talet, stötte jag ibland på teknologer från andra linjer som självsäkert hävdade att "Programmering, det lär man sig väl ändå. Det är lite if-satser och while-loopar. Hur svårt kan det vara?"

Linda Hall påminner också om en senare och mer officiell bekräftelse på hennes betydelse: den 22 november 2016 mottog hon Presidential Medal of Freedom av president Barack Obama.

Symbolvärdet förstärktes av det klassiska fotografiet där hon står bredvid den utskrivna koden, men också av senare hyllningar. Den mest storslagna kom den 18 juli 2019 när Google lät över 107 000 speglar vid Ivanpah-anläggningen i Mojaveöknen reflektera månljus så att ett enormt porträtt av Hamilton framträdde sett uppifrån. Det är svårt att tänka sig en bättre slutbild för denna historia. Kvinnan bakom programvaran som hjälpte människan till månen hyllades femtio år senare med samma himlakropps ljus.

I länksamlingen nederst finner du länk till artikeln som beskriver detta, samt vidare länk till videon.

Även populärkulturen har dragits mot hennes gestalt. I TV-serien For All Mankind har den fiktiva NASA-ingenjören Margo Madison enligt Physics Today inspirerats av historien om Hamilton. Det betyder inte att figuren är ett porträtt av henne, men det visar hur stark denna ikonografi blivit. Hamilton står inte längre bara för ett specifikt system eller ett visst uppdrag, utan för en viss idé om ingenjörskonst: klarhet under press, respekt för felens verklighet och en orubblig vilja att tänka ett steg längre än instruktionen kräver.

Det är därför Apollo 11:s styrprogram fortfarande känns samtida. Inte för att det liknar vår teknik i detalj, utan för att dess djupaste fråga fortfarande är vår egen: hur bygger man system som fortsätter att vara kloka när världen slutar vara förutsägbar?

Efterord

Det är fascinerande hur man kan snubbla på intressanta ting. Upprinnelsen till denna artikel var att jag fått syn på en YouTube-video om att Anthropic misslyckats med att bygga en fungerande C-kompilator med hjälp av Claude Code. "Hmm, intressant, tyckte jag". I videon fick jag reda på hur och varför, men också att några andra lyckats, med hjälp av deras egna "Dunder AI" Blitzy. Med Blitzy hade man byggt en helt fungerande C-kompilator i Rust, som bland annat kunde kompilera hela Linux-kärnan.

Så jag började kolla upp dem och deras blogg, där de skrev om arbetet med kompilatorn. Efter ett tag fick jag syn på en annan av deras artiklar som handlade om programvaran i Apollo 11. Det visade sig att de tagit Blitzy till hjälp att läsa och analysera programvaran för AGC (Apollo Guidance Computer).

Förutom koden fanns också ett analys- och sammanställningsdokument där framförallt terminologin och den kombinerade bildnings- och humornivån tilldrog sig mitt fulla intresse. Detta dokument inspirerade till denna artikel, i kombination med vidare uppgifter om Margaret Hamilton.

Jens Riboe jens.riboe@ribomation.se