Du har kanskje hørt om at det holdt på å gå galt med Apollo 11, da Eagle hadde kun noen sekunder med drivstoff igjen før landingen på månen måtte avbrytes? Og kanskje du har hørt om at Apollo 13 hadde en feil som resulterte i en eksplosjon som nesten kostet mannskapet livet, og gjorde at de ikke kunne lande på månen likevel?
Førstnevnte er så berømt at det har du nok, og hva Apollo 13 angår så ble den historien til en velkjent film med blant annet Tom Hanks. Og begge deler er dokumentert i BBC World Services kritikerroste podkast «13 Minutes to the Moon».
Men visste du at det holdt på å gå galt også med Apollo 12? Og ikke minst, at IT-bransjen den dag i dag har noe å lære av hva som skjedde, over 50 år etter dramaet?
Så, hva var det egentlig som skjedde?
Ikke så mye de første 36,5 sekundene eller så etter oppskytning, men så ble plutselig raketten truffet av et lyn. 16 sekunder senere skjedde det en gang til.
To lynnedslag under oppskytning, på under 20 sekunder, var ikke noe NASA hadde trent på.
Et typisk lynnedslag kan stille med omkring 300 millioner Volt og 30.000 Ampere, så det sier seg selv at dette kan påvirke et romfartøys systemer, som i Apollo-æraen stort sett gikk på 28 Volt. Dessuten, selv om den ikke var jordet, så er det likevel ikke akkurat ønskelig å sende såpass med elektrisitet gjennom en rakett som inneholder rundt regnet 3,3 millioner liter drivstoff, fordelt på parafin og flytende oksygen og hydrogen.
Det var ikke spesielt dårlig vær da Apollo 12 ble skutt opp den 14. november 1969. Det var overskyet og bygevær, men nedtellingen gikk uten problemer og ingen var egentlig bekymret for været. Apollo 12 ble skutt opp nøyaktig på planlagt tidspunkt klokken 11.23 om formiddagen, lokal tid.
Den enorme Saturn V-raketten fløy likevel inn i en tordensky på vei opp, og etter å ha truffet Apollo 12 fulgte lynet eksosstripen helt ned til oppskytningsrampen.
– Hva i helvete var det?
Astronautene om bord visste først ikke hva som hadde skjedd. Det første de merket var at alle tre brenselcellene falt ut. Systemet hadde automatisk koblet dem fra for å beskytte dem, siden spenningen økte dramatisk. Terskelen for frakobling var satt til en økning på 500 Volt per millisekund, og et lynnedslag overstiger det med temmelig mye.
Dermed gikk kommandomodulen deretter på batterikraft. Den hadde tre batterier – A, B og C – men C-batteriet var forbeholdt returen til bakken og var dermed frakoblet for øyeblikket, så bare A- og B-batteriene var tilgjengelige.
Den automatiske frakoblingen av brenselcellene var en brutal affære for systemet i kommandomodulen. De skulle egentlig forsyne 29 Volt, men på et øyeblikk falt spenningen til så lavt som 18 Volt, før systemet igjen tok seg inn til en stabil spenning på 24 Volt. Det plutselige spenningsfallet påvirket en masse instrumenter om bord, og i løpet av et sekund eller to lyste instrumentpanelet opp med flere advarselslamper enn mannskapet på tre noensinne hadde sett samtidig.
På dette punktet var det ingen av dem som visste hva som hadde skjedd.
At de bare 16 sekunder senere ble truffet av enda et lyn, gjorde ikke saken noe bedre. Det førte til en rekke nye feil og varsler. En eller flere av disse påvirket kommandomodulens datamaskin slik at den antok at navigasjonssystemet måtte kalibreres på nytt, og astronautenes kunstige horisont spant derfor ut av kontroll.
Kommunikasjonsloggen viser at kommandør Pete Conrad ti sekunder etter lynnedslag nummer to uttalte «Ok, vi har nettopp mistet plattformen, folkens. Jeg vet ikke hva som skjedde her; alt i hele verden falt nettopp ut».
Forvirringen var til å forstå: Instrumentene viste at romfartøyet spant ut av kontroll, men samtidig kunne astronautene føle på kroppen at raketten ennå virket å være på vei opp, med andre ord stort sett i riktig retning. De valgte å stole på magefølelse og erfaring, selv om en av dem satt med en hånd på avbryt-hendelen hele tiden mens dette pågikk.
Det astronautene ikke kunne vite, var at feilene kun var i kommandomodulens datamaskiner. Selve raketten hadde sine egne datasystemer, bygget av ikke ukjente IBM, og disse fungerte fremdeles som de skulle og holdt kjemperaketten på riktig kurs.
Ingen hjelp fra bakken
Det var heller ikke så mye hjelp å få fra kontrollrommet. Telemetrien de fikk fra fartøyet var bare rot og bestod tilsynelatende av tilfeldige tall. De hadde ikke data de kunne stole på, og dermed heller ikke noen måte å angripe problemet på, inntil John Aaron ble spurt om han hadde noen ideer. Han var EECOM, det vil si «Electrical, Environmental and Consumables Manager». Han fikk ikke noe bedre data enn de andre, men så noe kjent i kaoset skjermene viste.
Det har blitt sagt at han kjente det igjen fra en øvelse han hadde vært vitne til, men det er ikke riktig. Ingen øvelsesinstrumenter hos NASA var i stand til å simulere et slikt mønster av feil, rot og feilinformasjon med hensikt, men Aaron hadde sett noe lignende tidligere da instrumentene ble testet og en gruppe teknikere rotet det til og tilfeldigvis ga dem for lav spenning.
I stedet for å vise nullverdier, genererte instrumentene disse merkelige mønstrene som han kjente igjen, uttalte han i ettertid til NASA Oral History Project.
Nøyaktig 60 sekunder etter det første lynet traff, kom han med den berømte anbefalingen:
– Prøv SCE til AUX.
Verken i kontrollrommet eller i kapselen var det noen som forstod hva han snakket om, men de stolte på at han kjente systemet bedre enn noen andre – noe han også gjorde, tross sin unge alder. Han var bare 24 år gammel.
Kommunikasjonsloggen viser at man i kapselen og på kontrollrommet refererte til SCE som både NCE og FCE i sekundene som fulgte. Det betyr ikke nødvendigvis noe annet enn at radiokommunikasjonen ikke var optimal, men det kan også indikere at dette var en bryter mange ikke kjente til. Den satt helt nede til høyre på et temmelig stort og komplisert instrumentpanel og det var svært sjelden behov for å gjøre noe med den.
Slå den av og på igjen
SCE er kort for «Signal Conditioning Equipment» og var essensielt en boks full av elektronikk som mottok impulser fra en rekke sensorer over hele romfartøyet, med en rekke ulike spenningsverdier. SCE konverterte disse spenningene til et spenn på 0–5 Volt for å klargjøre dem til å sendes til kontrollrommet som telemetri. Dette var med andre ord et viktig instrument, og hadde som sådan en redundant strømforsyning.
Vanligvis ville SCE skiftet strømforsyning automatisk, men etter lynnedslaget på Apollo 12 hadde begge strømforsyningene fått et spenningsfall, så å skifte fra en til den andre ville ikke gjort noen forskjell. Spenningsfallet fra 28 Volt og ned til 18–19 Volt var for drøy til at systemet klarte å takle det. Noen kilder sier at terskelspenningen for dette var 22,9 Volt, så selv om spenningen etter noen millisekunder steg til 24 Volt, var det likevel ikke nok. Systemet klarte ikke å starte opp igjen automatisk, og dermed ble telemetrien sendt til kontrollrommet bare rot.
Det er litt uklart hvorfor å manuelt sette SCE til AUX fikset problemet når ikke automatikken gjorde det, men sannsynligvis omgikk den manuelle innstillingen en del sikkerhetssjekker i systemet som hindret instrumentene i å fungere optimalt på 24 Volt, som altså var 4 Volt lavere enn de var laget for å bruke.
Uansett gjorde det susen, brenselcellene ble koblet til igjen, og kontrollrommet fikk tilbake dataene slik at de kunne begynne med å finne, sjekke og korrigere de resterende feilene.
Hadde de ikke kunnet gjøre det, hadde sannsynligvis hele Apollo 12 blitt avbrutt der og da.
Det var først et minutt eller to senere at det gikk opp for mannskapet at de kanskje hadde blitt truffet av lynet.
Dagens IT-hoder vil utvilsomt finne glede i å konstatere at SCE-bryteren hadde tre innstillinger: Normal, av, og AUX. For å slå den over fra normal til AUX måtte den nødvendigvis innom av-innstillingen, og dermed kan det sies at astronautene slo SCE av og på igjen – den kjente universalløsningen på dataproblemer.
I videoen nedenfor forteller Tom Hanks og NASA-aktørene selv hva som skjedde:
Slapp ikke uskadd unna
Noen kilder sier at Apollo 12 slapp uskadd unna de to lynnedslagene, men det er ikke riktig. Flere systemer ble midlertidig slått ut, og andre fikk feil i sine data. I tillegg kunne ikke NASA være sikker på at ikke også andre systemer kunne ha korrupte data, så mens Apollo 12 var i bane måtte mange ulike instrumenter kalibreres og stilles inn på nytt, noe som tok tid. Det var også enkelte sensorer som tok kvelden for godt, men heldigvis ikke noe man ikke kunne klare seg uten.
Det vil si, det var en ting NASA var usikre på: Hadde fallskjermenes utløsermekanisme tatt skade av hendelsen, eller ikke? Det var umulig å teste det uten å faktisk fyre dem av, noe man ikke kunne gjøre før fartøyet uansett skulle returnere til Jorden. Dermed bestemte NASA etter sigende seg for å ikke nevne noe om det til astronautene om bord. På den måten fikk de i det minste en tur til månen før de kanskje krasjet i havet i stor hastighet. Det er uvisst hva astronautene mente om den avgjørelsen.
Apollo 12 landet som planlagt på månen den 24. november 1969, passende nok i Stormenes hav («Oceanus Procellarum»).
Lærdom den dag i dag
IT-bloggeren Michael Gat bruker denne historien til å illustrere et knippe læringspunkter han mener er viktige også for dagens IT-bransje. Kort oppsummert:
- Det er viktig å trene og øve på ulike scenarioer. Ikke nødvendigvis fordi man skal gjenskape alle muligheter, men fordi det er viktig å skape en nær kjennskap til systemer man arbeider med. Som han påpeker ble situasjonen som oppstod i Apollo 12 aldri simulert – den kunne ikke simuleres – men en feil under testing førte til at Aaron kunne gjenkjenne et mønster, og det var nok til å kunne diagnostisere problemet på noen kritiske sekunder.
- Vær nysgjerrig og gå i dybden. Selv om det tilsynelatende ikke har en direkte verdi, kan det oppstå situasjoner der kunnskap derfra er kritisk. Som det var da Aaron ikke var involvert i testen som gikk galt, men valgte å observere likevel, og undersøke nærmere da han så noe han ikke forstod.
- Hør på juniorene. Bare fordi de er unge og kan være uerfarne, betyr ikke det at de ikke sitter på viktig kunnskap om prosjektet. Stol på at de kan jobben sin.
- Ikke gjør noe bare for å gjøre noe, og ikke gjør ingenting hvis det er noe du kan gjøre. Praksis på Apollo var å ikke røre innstillinger før det var absolutt nødvendig, selv med en mulig avbrytelse av oppdraget pustende deg i nakken. I IT-bransjen kan et viktig spørsmål ofte være «hva kan jeg prøve som kan hjelpe, og som ikke vil gjøre situasjonen verre?»
- Ikke la en mulig løsning stoppe deg fra å vurdere andre mulige løsninger. Ingen visste om «SCE til AUX» ville fungere før de prøvde det, og mens det hele pågikk prøve både kontrollrommet og astronautene å finne løsninger. I flertall.
