20. júla 1969 o 20:15 UTC sa lunárny modul Apolla 11 zvaný Eagle blížil k mesačnému povrchu. Veliteľ Neil Armstrong a pilot lunárneho modulu Buzz Aldrin mierili k pristávacej zóne v Sea of Tranquility.

Uprostred príprav na pristátie sa v rádiu ozval zvýšený hlas Neila Armstronga nesúci známky neočakávanej udalosti: ”Máme tu alarm 1202… Čo to znamená?”. Prístroje indikovali neočakávané výsledky výpočtov navigačného počítača Apollo Guidance Computer (AGC). Vlna prerušení vyčerpala výpočtovú kapacitu počítača lunárneho modulu a spôsobila alarm. Ale to už predbiehame. Poďme sa pozrieť na dlhú históriu vývoja palubných počítačov Apollo, ktorá predchádzala dramatickým okamihom pred prvým pristátím človeka na mesačnom povrchu.

Veľkou výzvou NASA v 60. rokoch bol vývoj palubného počítača, ktorý by zabezpečil kontrolu letových procesov ako napr.: navigácia, rendez-vous (priblíženie a spojenie vo vesmíre), návrat do atmosféry a ďalšie nevyhnutné letové procesy. Požiadavky kladené na odolnosť a spoľahlivosť hardvéru rovnako aj softvéru sa vymykali potrebám kladeným na počítače používané v kontrolných strediskách na zemi. Vesmírna radiácia, vibrácie vznikajúce pri štarte raketoplánu a spoľahlivosť softvéru, ktorý ovláda kozmickú loď s ľudskou posádkou, to všetko boli v tej dobe veľmi málo preskúmané oblasti v leteckom a kozmickom inžinierstve.

Predtým ako došlo k tomu, že prezident John F. Kennedy vo svojom príhovore na spoločnom zasadnutí oboch komôr kongresu povedal tieto známe slová „Som presvedčený, že tento národ by sa mal zaviazať do konca tejto dekády dosiahnuť cieľ poslať človeka na Mesiac a bezpečne ho vrátiť na Zem.“ Bolo nevyhnutné preskúmať či je možné bezpečne navigovať a pristáť s kozmickou loďou viac ako 250 tisíc kilometrov od miesta štartu. Ľudia z Instrumentation Laboratory sídliacom na Massachusetts Institute of Technology (MIT) pracovali na tejto úlohe už od konca 50. rokov. Prvé palubne počítače navrhnuté pre lety na Mesiac a na Mars, spracovávali programy jeden po druhom v takzvaných dávkach (batch). Časť navigačných a kontrolných výpočtov bola spracovávaná počítačmi, ktoré boli na Zemi a výsledky sa následne vysielali do kozmickej lodi. Fyzikálna realita 1,5 sekundového oneskorenia prenosu signálu zo Zeme na Mesiac nedovoľovala využitie tohto princípu aj pre kontrolu pristávania na povrchu Mesiaca. Preto bolo nevyhnutné vyvinúť hardvér a softvér, ktorý by zabezpečil autonómnu kontrolu procesu pristávania za asistencie ľudskej posádky. Táto úloha palubného počítača pre úspešný let a pristátie sa stala natoľko dôležitou, že inžinieri začali nazývať tento systém štvrtým členom posádky.

Misia letu na Mesiac s ľudskou posádkou spájala operácie dvoch hlavných modulov kozmickej lode: veliteľský modul (CM = Command Module) na mesačnom orbite a modul LEM (Lunar Excursion Module), ktorého úlohou bolo bezpečné oddelenie sa od veliteľského modulu a bezpečne dopraviť človeka k jeho prvému kroku na povrchu Mesiaca. Počítač umiestnený v moduloch CM a LEM pozostával z rovnakého hardvéru, avšak v každom module bol rozdielny softvér. NASA pomenovala tieto dva hlavné palubné počítače – Primary Guidance, Navigation and Control System (PGNCS). Modul LEM obsahoval ešte dodatočný počítač, ktorý bol súčasťou AGS (Abort Guidance System) – išlo o záložný systém pre návrat k veliteľskému modulu v prípade zlyhania hlavného počítača.  

Block I

Prvá varianta hlavného (palubného) počítača modulov CM a LEM nazývaná Block I trpela vážnymi nedostatkami. Jej stredná doba medzi poruchami (MTBF) bola asi 4200 hodín. Mean Time Between Failures alebo skrátene MTBF je ukazovateľ kvality, ktorý vyjadruje štatistickú spoľahlivosť komponentu alebo systému [4]. Hodnota MTBF ktorú dosiahli palubné počítače pre CM a LEM modul 4200 hodín, bola asi 20 násobne väčšia ako hodnota pre akúkoľvek dovtedy plánovanú misiu. Block I používal takzvaný “destructive readout” čo v jednoduchosti znamená, že po prečítaní požadovanej informácie z pamäte sa táto informácia stratila. Palubný počítač Block I mal však jeden vážny problém – vyskytol sa u neho problém s nestabilnou dobou čítania informácii z pamäte. Priemerný čas čítania z pamäte bol pri Block I asi 19,5 milisekundy čo malo za následok spomalenie programu a taktiež sa začali vyskytovať aj rôzne problémy pri vykonávaní niektorých úloh.

Block II

V roku 1962 začala MIT skúmať možnosť použitia integrovaných obvodov (IC = Integrated Circuit) ako alternatívu k tranzistorom, ktoré sa použili v palubnom počítači Block I. Výskumníci z MIT sa rozhodli pre  technológiu directly coupled transistor logic (DCTL [5]) typu NOR. Pri DCTL ide o priame spojenie kolektora tranzistora s bázou nasledujúceho tranzistora [5]. Počítač letu Apollo 11 bol zložený z takmer 5000 takýchto “malých” integrovaných obvodov. Do konca leta v roku 1963 program Apollo spotrebúval skoro  60 % produkcie týchto mikroobvodov v celej USA. Vďaka tejto usilovnej práci bol nový palubný počítač letu Apollo čoskoro na svete, nazvali ho “prekvapujúco” Block II. Pamäť použitá pre Block II mala dva krát väčšiu kapacitu ako pamäť pre Block I, rovnako došlo aj k zmenšeniu rozmerov  pamäte a energetickej náročnosti. Jedným z hlavných prínosov prechodu na palubný počítač Block II bolo zvýšenie spoľahlivosti.

Pre predstavu, palubný počítač Apolla, Block II, vážil približne 30 kg a bol asi 60 x 30 x 15 cm veľký. Na 28 V jednosmerného napätia vyžadoval Block II 70 Wattov. Posádka s počítačom komunikovala pomocou klávesnice a malého displeja (DSKY = display and keyboard unit). 

Obr. 1: Apollo 11 AGC s ovládacou konzolou DSKY (na pravo). Zdroj: Wikipedia.org.

Veľa počítačov v tej dobe používalo dĺžku slova 24 alebo viac bitov. Pre počítač Apolla 11 bolo zvolené slovo o dĺžke len 16 bitov. Dôvodom pre tento krok bol jednoduchší dizajn obvodov a potreby kladené na presnosť vstupných údajov. Reťazec pozostával zo 14 bitov slúžiacich na uloženie hodnoty, 1 bitu pre znamienko a 1 bitu pre paritu. V prípade potreby väčšej presnosti bolo možné použiť viacero slov na reprezentáciu jednej hodnoty. Inštrukcie využívali bity 15 až 13 v slove pre vyjadrenie inštrukcie a bity 12 až 1  sa využívali pre adresu. 

Obr. 2 – Ukážka core-rope pamäte na Apollo 11

Vnútorne hodiny Block II mali rýchlosť 1 MHz. Pamäť bola rozdelená na blok pamäte RAM a blok takzvanej core rope pamäte (vodivých drôtov vedených cez feritové prstence – feritová pamäť). Core rope memory bola typu ROM. Každý feritový prstenec reprezentoval 1 bit informácie. Ak bol drôt vedený vnútrom prstenca, nadobudnutá hodnota bola interpretovaná ako logická 1. V opačnom prípade bola nadobudnutá hodnota logická 0. Pre uloženie asi 2000 bitov bolo potrebných približne 16 cm kubických priestoru. Prvý návrh MIT zahŕňal iba 4K slov pamäte ROM a 256 slov pamäte RAM. Počas programu Apollo sa veľkosť pamäte niekoľkokrát upravovala. V konečnej verzii mala ROM pamäť kapacitu 36K slov a pamäť RAM mala 2K slov. Dôvodom zväčšovania pamäte bolo, že na začiatku programu neboli zo strany NASA hotové všetky špecifikácie funkcii potrebných pre úspešne splnenie misie.

Obr. 3: Príklad schémy core rope pamäte. Zdroj: Computers in Spaceflight [1]

Vývoj software pre počítač s core rope memory obmedzoval jeho tvorcov vo viacerých smeroch. Program musel byť hotový mesiace pred začatím misie aby bolo možné vyrobiť a otestovať nemenné obvody. Softvérové inžinierstvo bolo na začiatku 60. rokov stále v začiatkoch. Inžinieri predpokladali výskyt chýb vo vytvorených programoch. Niektoré chyby bolo možné opraviť výrobou nových modulov. Niektoré chyby však z časových dôvodov opravene neboli a bolo nutne s nimi počas letu počítať. NASA získala vývojom softvéru pre program Apollo, neoceniteľné skúsenosti. Tieto skúsenosti mali neskôr veľký vplyv pri vývoji softvéru pre program raketoplánov. 

Kvalita Apollo softvéru, bola na začiatku programu nízka. Bolo potrebné zaviesť cyklus vývoja softvéru obsahujúci špecifikáciu, dizajn, implementáciu, testovanie a údržbu. Report Bellcom z roku 1964 [2] prináša mnoho návrhov, ktoré sa uplatňujú pri vývoji softvéru dodnes. Počiatočný predpoklad, že softvér je možné vyvíjať rovnakým spôsobom ako hardvér spôsobil v programe Apollo časove, finančne aj kvalitatívne problémy. K úspešnému dokončeniu softvéru pre PGNCS a AGS prispelo zmenšenie vývojových tímov (ktoré svojho času počítali na 2000 programátorov), vytvorenie komisii pre kontrolu vývoja softvéru a prijatie vývojových a review procesov prispôsobených potrebám vývoja. Ustanovené míľniky vývoja a revízii ako PDR (Preliminary Design Review) a CDR (Critical Design Review) sú súčasťou softvérových štandardov vo svete aerospace dodnes.

Letový softvér pre počítače CM aj LEM bol vyvinutý na počítačoch Honeywell 1800 a neskôr IBM 360. Skutočný letový hardvér nebol pri vývoji programov použitý. Vývojové počítače vygenerovali binárny kód. Pásky s programom boli otestovane a poslane výrobcom core rope pamätí.

Apollo Guidance Computer podrobnejšie

Apollo Guidance Computer (AGC), ktorý bol súčasťou PGNCS, používal priority-interrupt systém schopný vykonávať niekoľko úloh naraz, pričom prednosť bola daná úlohe s najvyššou prioritou. Tento druh operačného systému je rozdielny od takzvaných “round-robin” systémov, v ktorých je pre každú úlohu vyhradený časový úsek a úlohy sa v rovnakom poradí periodicky opakujú. Operačný systém AGC obsahoval dva mechanizmy pre plánovanie úloh: Executive, ktorý vedel vykonávať až 8 úloh naraz a Waitlist, ktorý vykonával až 9 krátkych úloh kratších ako 4 ms. Ak sa niektorá z úloh vykonávala dlhšie ako 4 ms, dostala automaticky status úlohy pre Executive a bola zaradená do jeho fronty. Executive testoval periodicky každých 20 ms či sa vo fronte neobjavila úloha s vyššou prioritou. Ak executive nenašiel žiadnu úlohu, ktorú bolo potrebné vykonať, periodicky vykonával úlohu nazvanú DUMMY JOB pokiaľ sa neobjavila nová úloha.  

Úlohy zaradené do fronty kontrolného mechanizmu Executive v operačnom systéme AGC zdieľali 12 pamäťových miest v pamäti RAM, takzvaný “coreset”. Interpretované funkcie (popísané nižšie) mali pridelených ďalších 43 pamäťových miest pre takzvaný vector accumulation (VAC). AGC v LEM mal dohromady 8 “coresets” – jeden pre každú naplánovanú úlohu. Ak sa objavila nová, deviata úloha s vysokou prioritou, ktorú bolo treba vykonať, Executive sa pokúsil zastaviť úlohy s nízkou prioritou a reštartovať iba úlohy s vysokou prioritou vrátane novej úlohy. Priradenie “coreset” novej úlohe vykonávala funkcia NEXTCORE, ktorú pre ilustráciu uvádzame nižšie.

Obr. 4: Ilustrácia "coresets" v operačnom systéme AGC

Operačný systém AGC patril do skupiny takzvaných real-time systémov. V real-time systéme, má každá vykonávaná úloha stanovený čas do ktorého sa musí vykonať (takzvaný “deadline”). Analýzou všetkých vykonávaných úloh (dĺžky času ich vykonávania, ich priority a času začatia ich vykonávania) sa overuje, že systém má dostatočnú výpočtovú kapacitu na vykonanie daných funkcii v požadovanom časovom úseku. Tieto analýzy neboli v čase vývoja AGC ešte dostatočne rozvinuté, čo spôsobovalo problémy s občasným preťažením systému signálmi z ostatných zariadení.

Aj keď väčšina programátorov softvéru Apollo poznala assembler, už od počiatku programu bolo zrejmé, že programovať počítače na tejto úrovni by prinieslo neudržateľný nárast chybovosti. MIT preto vyvinula špeciálny jazyk vyššej úrovne. Program bol preložený do určitého počtu funkcií, ktoré boli počas letu interpretované. Pôvodných 11 inštrukcii, ktoré obsahoval assembler bolo použitých na vytvorenie 128 interpretovaných funkcii.  Rýchlosť vykonávania podfunkcii bola pomalšia ako porovnateľný program napísaný v assembleri, ale zvýšila sa spoľahlivosť a znížili sa pamäťové nároky. 

Na vyššej úrovni bol softvér pre misie Apollo rozdelený do série programov používaných v rôznych fázach letu. Pristátie na mesačnom povrchu sa začínalo programom P63 po spomalení letu a začatí pristávacieho manévru. Pristátie pokračovalo programom P64 a jeho záverečnú fázu až do historického pristátia na povrchu Mesiaca obsluhoval program P66. Ovládanie palubných počítačov Apollo pomocou konzoly DSKY kládlo na astronautov veľké nároky. Odhaduje sa, že splnenie lunárnej misie si vyžadovalo približne 10500 stlačení ovládacích tlačidiel. 

Obr. 5: Ukážka časti programu AGC (program EXECUTIVE.agc). Zdroj: medium.com.

Výpis programov modulu AGC je dostupný prostredníctvom webového portálu GitHub na adrese: https://github.com/virtualagc/virtualagc. Program na Obr. 5 je jedna z mnohých funkcií (“subroutine”) nazvaná NEXTCORE. Ostatne časti programu mohli volať tuto funkciu prostredníctvom inštrukcie TC (Transfer Control). 

Neočakávaný reštart počítača počas letu bol navrhnutý tak, že sa vykonávanie programu prenieslo na preddefinovanú adresu, na ktorej bol program pre vyčistenie výstupných kanálov (napríklad ovládanie výstražných kontroliek alebo ovládanie trysiek motorov) a program určenia miesta pokračovania prerušených bežiacich úloh. 

PGNCS problém

Vráťme sa krátko k chybovým hláškam pri pristáti Apolla 11, 1201 a 1202, ktoré sa objavili vo fáze pristátia na programe P64. Za tie zodpovedal Primary Guidance, Navigation and Control System alias PGNCS. Prvý alarm 1201 značil "executive Overflow – no vacant areas", 1202 potom "executive overflow – no core sets". V oboch prípadoch išlo o chyby vyvolané falošnými údajmi z približovacieho radaru, ktorý bol počas zostupu ponechaný svojmu osudu. Akonáhle samostatný pristávací radar zachytil povrch mesiaca, AGC začal spracovávať aj dáta z približovacieho radaru, došlo k niekoľkým týmto pretečeniam, pretože do systému jednoducho prúdilo viac údajov, než bol schopný v reálnom čase spracovávať. Pretečenia automaticky prerušovali beh aktuálnej úlohy, ale aj tak dostával AGC stále príliš veľa dát z oboch radarov.

Slovo záverom

Program vývoja software pre misie Apollo trpel v priebehu svojho trvania mnohými nedostatkami. V Júni 1966 po dôkladnom audite bolo zistené, že program pre let AS-204 (prvý let s ľudskou posádkou) obsahoval chyby v každom zo svojich modulov. Niektoré moduly neboli podlá známeho reportu Howarda W. Tindalla [3] testovane vôbec. Vylepšenia v softvéri navrhované posádkou boli zamietnuté z časových dôvodov. 

Vývoj hardvéru a softvéru počas misii Apollo v NASA prešiel mnohými zmenami. Najdôležitejšie zistenia o dôležitosti vstupných požiadaviek a dokumentácii riešenia a programov, verifikácie na viacerých úrovniach a že viac inžinierov a programátorov neznamená rýchlejší výsledok platia vo veľkom rozsahu dodnes. Výsledná kvalita sa po zapracovaní zmien vo vývojových procesoch ukázala ako vyhovujúca pre misie Apollo a Neil Armstrong tak mohol preniesť historické slová o malom kroku pre človeka ale veľkom kroku pre ľudstvo.

[1] Tomayko, “Computers in Spaceflight”.

[2] Bellcomm, Inc., “Procedures for Management and Control of Computer Programming in Apollo”.

[3] Tindall, "Apollo Spacecraft Computer Programs-Or, A Bucket of Worms."

[4] MTTR, MTBF, or MTTF? – A Simple Guide To Failure Metrics https://limblecmms.com/blog/mttr-mtbf-mttf-guide-to-failure-metrics/

[5] Direct Coupled Transistor Logic (DCTL) https://electronicspani.com/direct-coupled-transistor-logic-dctl/

O autorovi

Slavomír Petrík

Participoval na vývoji softvéru rovera pre misiu Mars 2020,  tvorca real-time operačného systému pre palubný počítač skCUBE. V súčastnosti sa prostredníctvom firmy https://www.12gfs.com/ venuje vývoju komunikačného stacku PUSopen® určeného pre Cubesaty.

Jazyková korektúra: kolektív redakcie ( Ondrej Závodský, Jozef Slížik, Ľubomír Pasternák )

• O autorovi
• Najnovšie príspevky

zawin

Administrátor webu SVETELEKTRO.COM. Pracujem vo firme GOSPACE TECH ako HW a SW inžinier v oblasti IoT - www.fleximodo.com

Najnovšie články od zawin (zobraziť všetky)

• Novinky na webe SVETELEKTRO - 12. decembra 2020
• TEPLOMĚR DO UDÍRNY - 21. júla 2020
• Výsledky súťaže o najlepší výrobok–4. kolo - 23. decembra 2019