Počítač Apolla 11 přetížil zapnutý radar, přesto dokázal přistání dokončit

20. července 1969 spustil palubní počítač lunárního modulu Eagle pět alarmů, které nikdo z posádky nedokázal identifikovat. Houston měl sekundy na rozhodnutí, zda přistání přerušit.

Foto: Arjun Sarup - licence CC BY-SA 4.0

Neil Armstrong právě sledoval měsíční povrch, když se na displeji DSKY rozsvítil kód 1202. „Program Alarm,“ ohlásil Buzz Aldrin do rádia a vzápětí požádal o vysvětlení. V řídícím středisku v Houstonu se ve zlomku okamžiku rozběhl rozhodovací řetězec, na jehož konci stál šestadvacetiletý Steve Bales s jedinou odpovědí: „GO on that alarm.“

Radar, který kradl procesorový čas

Příčina alarmů neležela v samotném navigačním softwaru, ale v setkávacím radaru. Podle kontrolního seznamu měl být jeho přepínač před zahájením sestupového programu P63 v poloze AUTO TRACK. V tomto režimu vznikal mezi dvěma referenčními signály o frekvenci 800 Hz náhodný fázový vztah a elektronika radaru začala generovat falešné impulzy s frekvencí až 6 400 za sekundu. Každý z nich vyžadoval pozornost procesoru.

Technická analýza MIT ze 4. srpna 1969 vyčíslila ztrátu na přibližně 15 % výpočetního času. Přitom software byl testován pouze na 10% rezervu. Počítač lunárního modulu, stroj s 2 048 slovy přepisovatelné paměti a taktem, při kterém jedno sčítání trvalo 23,4 mikrosekundy, narazil na hranici, s níž nikdo nepočítal. Ne proto, že by ji inženýři podcenili, ale proto, že kombinace checklistu a hardwarového rozhraní vytvořila zátěž, kterou žádný předletový test nepokryl.

Čtyři minuty, pět alarmů, jedno rozhodnutí

První alarm 1202 přišel zhruba 316 sekund po zapálení sestupového motoru, ve výšce kolem deseti kilometrů. Eagle byl vysoko, daleko od povrchu, ale Houston měl jen krátké okno na verdikt. Během následujících čtyř minut se alarmy opakovaly: dvakrát 1202, třikrát 1201. Poslední tři přišly v rychlém sledu během asi čtyřiceti sekund, už ve fázi P64, kdy Armstrong manuálně vybíral místo dosednutí.

Posádka nevěděla, co přesně se děje. Armstrong požádal Houston o „reading on the 1202″. Aldrin reagoval prakticky a omezil zobrazování některých údajů, aby počítači ubral práci. Na druhé straně Atlantiku, v budově MIT v Cambridge, sledoval přenos Don Eyles, spoluautor přistávacího softwaru. Později napsal: „V hlavě se mi rozezněl křik: přerušte to.“ Nikdy předtím nepočítali s tím, že by se po alarmu 1202 v přistání pokračovalo.

A přece se pokračovalo. V závěru sestupové fáze zaznělo z Houstonu hlášení „60 seconds“– tolik paliva zbývalo. Pak „30 seconds“. Eagle dosedl s rezervou pouhých několika sekund letu.

Proč počítač nespadl

Klíčem k přežití nebyl hardware, ale architektura softwaru. Palubní počítač AGC používal systém správy úloh nazvaný EXECUTIVE a WAITLIST, v podstatě prioritní plánovač, který přiděloval procesorový čas podle důležitosti. Když zátěž přesáhla kapacitu, spustila se takzvaná rutina BAILOUT. Ta vyčistila fronty, odstranila méně důležité úlohy (typicky zobrazování rozšířených dat na displeji) a znovu spustila pouze kritické procesy: řízení sestupového motoru, navigaci, základní komunikaci s DSKY.

Navigační data přitom zůstala zachována. Restart nevymazal polohu ani rychlost, pouze reorganizoval pořadí výpočtů. Byl to princip, který dnes považujeme za samozřejmost u kritických systémů: software nemusí být bezchybný, ale musí selhávat řízeně.

Autorem této plánovací architektury byl J. H. Laning Jr. z MIT Instrumentation Laboratory. Jeho návrh z poloviny šedesátých let předběhl dobu; asynchronní řízení úloh v reálném čase podle priorit bylo v éře analogových autopilotů a mechanicky zálohovaných systémů něco zcela neobvyklého.

Simulace, která změnila všechno

Příběh má ještě jednu vrstvu, bez které by rozhodnutí „GO“ nikdy nepadlo. Několik dní před startem Apolla 11 proběhla závěrečná simulace sestupu. Operátor simulátoru do ní záměrně vložil programové alarmy. Bales tehdy doporučil přerušení mise a po vyhodnocení simulace mu Gene Kranz nařídil, aby spolu s Jackem Garmanem z podpůrného sálu a lidmi z MIT prošli všechny kódy alarmů a vytvořili jasná pravidla: které alarmy vyžadují přerušení mise a které ne.

Garman si výsledek zapsal na papír. Když 20. července přišel první skutečný alarm 1202, podíval se na seznam a během sekund potvrdil Balesovi: dočasné přetížení, ne ztráta řízení. Bales řekl „GO“. Charlie Duke toto rozhodnutí předal posádce. Celý řetězec trval méně času, než trvá přečíst tento odstavec.

Na zemi přitom pracovalo pět sálových počítačů IBM System/360 Model 75 s řádově větší pamětí i výkonem. Na palubě Eagle byl jediný počítač AGC o velikosti kufříku. Rozdíl nebyl jen v číslech, ale v tom, že pozemní stroje měly luxus redundance a lidské obsluhy, zatímco AGC musel fungovat autonomně, v reálném čase, bez druhé šance.

Dědictví, které přežilo program Apollo

NASA si z Apolla 11 odnesla tvrdou lekci o rozhraní mezi hardwarem a softwarem. MIT po misi doporučilo přísnější dokumentaci, revizi checklistů hardwarovými specialisty a vyšší věrnost simulátorů. Dlouhodobě se zkušenost propsala do vývoje raketoplánu: jazyk HAL/S, nezávislý záložní letový systém i mnohem přísnější verifikační procesy měly kořeny právě v tom, co se 20. července 1969 málem pokazilo.

Princip řízeného selhání, který Laningův plánovač předvedl nad Mořem klidu, dnes najdeme v leteckých řídících systémech, v autonomních vozidlech, v serverových architekturách. Apollo 11 neukázalo, že počítače mohou selhat. Ukázalo, že správně navržený počítač může selhat, a přesto přistát.