Kosmonautika je špičkový obor lidské činnosti, který chyby odpouští jen výjimečně. Stroje, které se vydávají do kosmických hlubin jsou důkladně testovány na Zemi, aby se mohly připravit na všechny možné scénáře, které je ve vesmíru čekají. I přes tyto hloubkové testy ale občas dojde k selhání. Prakticky vždy se jedná o nějakou drobnost, na první pohled nevýznamný detail, ale jeho důsledky bývají dalekosáhlé. Nejznámějším příkladem je asi ztráta americké sondy Mars Climate Orbiter, která očekávala data v metrických mírách, zatímco řídící středisko posílalo údaje v mírách anglosaských. Dnešní článek ukáže, že i v současné době se může něco podobného stát.
Pokaždé, když do kosmu letí kosmická loď na svou premiérovou cestu, jsou všichni napjatí. Jedná se totiž o tolik komplexní stroj, že pravděpodobnost selhání není malá. Když se vloni k ISS poprvé vydala loď Dragon, překvapily ji nečekané odrazy laserů od japonského modulu Kibó – s tím nikdo předem nepočítal. Pozemní týmy ale reagovaly rychle a připojení mohlo pokračovat jen s drobným zpožděním. Před pár dny se k Mezinárodní vesmírné stanici vydala další nová kosmická loď – tentokrát Cygnus. A nečekaný problém přišel znovu, jen v jiné podobě.
Let Cygnusu probíhal přesně podle plánu, loď reagovala správně na všechny zasílané pokyny a zdálo se, že jejímu spojení s ISS nebude nic bránit. Loď se tedy přiblížila do vzdálenosti 15 kilometrů od stanice a přesně podle naprogramovaného scénáře si s obytným komplexem začala vyměňovat údaje o vzájemné poloze. Do této doby totiž obě tělesa dělila velká vzdálenost, loď tedy nemohla se stanicí komunikovat. Navíc s klesající vzdáleností roste nutnost přesnější navigace.
Zdroj: http://www.americaspace.com/
Cygnus byl ale z dat, která dostal od stanice zmatený. Neseděl mu totiž formát GPS dat. Řídící počítač to zcela pochopitelně vyhodnotil jako nestandardní situaci a zastavil celý přibližovací manévr. Abychom mohli správně pochopit příčinu nesouladu, opustíme na chvíli Cygnus a zaměříme se na technologii, se kterou GPS pracuje. Abychom mohli určit svou polohu, potřebujeme mít kontakt s několika satelity a kromě toho musíme pracovat se správným časem – každý satelit GPS proto na své palubě nese superpřesné rubidiové hodiny. Pokud to hodně zjednoduším – je potřeba vědět, kdy signál ze které družice vyletěl, aby bylo možné spočítat, jaká vzdálenost nás od družice dělí.
Jenže je tu jeden problém – Existují dva formáty času, které se pro GPS mohou požívat. Jeden totiž začíná s číslováním v roce 1980 (10-bit), druhý v roce 1999 (13-bit). Samotný časový formát vychází z počtu týdnů. Pokud bychom srovnali hodnoty obou verzí, lišily by se o 1024. Na ISS v modulu Kibó je nainstalovaný přístroj SIGI (Space Integrated INS [Inertial Navigation System]\GPS). Ten v rámci programu PROX vysílá údaje vztažené k referenčnímu roku 1999. Ano, hádáte správně, Cygnus očekával údaje s referenčním rokem 1980. Co se tedy Cygnusu zdálo? Po přepočítání mu vycházelo, že je rok 1994.
Možná si říkáte jak je možné, že se na tuto chybu nepřišlo při pozemním testování – zkoušela se totiž vzájemná komunikace lodi s maketou systému SIGI. Tady běželo všechno dobře. Proč? Protože systém SIGI používaný na Zemi byl také nastavený na referenční rok 1980. Na první pohled pitomá chyba, která se při pozemním testování odhaluje jen velmi těžko. Na oběžné dráze ale způsobila zastavení přibližovacího manévru. Naštěstí nebyly následky horší. Pozemní týmy závadu rychle odhalily a za chvíli byla k dispozici softwarová záplata. Nebylo to nic těžkého, stačilo Cygnusu říct: „Ke všem svým časovým GPS hodnotám přičti 1024 a s výslednou hodnotou dál pracuj.“ Záplata se otestovala na Zemi a v noci z neděle na pondělí se úspěšně nahrála do palubního systému soukromé lodi. Následovat musel restart řídícího počítače, což byl ostatně hlavní důvod, proč se tato procedura musela odehrát v dostatečné vzdálenosti od ISS.
Zdroj: http://iss.jaxa.jp/
Možná někoho z vás napadne, proč se na problém nepřišlo během příletu některé z předchozích lodí. Důvodem je shoda náhod. V první řadě tu máme loď HTV – ta během svého přiblížení systém PROX vůbec nepoužívá, takže je z obliga. Dále tu máme komerční Dragon. Ten sice využívá data PROX ze SIGI, ale nikoliv z japonského, ale z amerického modulu. Tím pádem se ani během jeho příletů na chybu nemohlo přijít.
Jak jsme si již řekli, tato závada neměla žádné fatální následky, jen se přílet odložil o necelý týden. Druhá část článku se ale bude věnovat případu, kdy měla nečekaná softwarová chyba za následek definitivní selhání sondy Deep impact. NASA sice definitivně nepotvrdila příčinu její ztráty, ale nejpravděpodobněji se jeví chyba, která nám opět přijde na první pohled jako malicherná drobnost, kterou bychom s trochou fantazie mohli přirovnat k fenoménu Y2K (aktuální byl před rokem 2000, kdy hrozilo, že počítače nezvládnou přechod data z formátu 19xx na 20xx).
Zdroj: http://i.space.com/
Sonda používala pro všechny své úkony časový formát uložený ve 32-bitovém formátu, který počítal desetiny sekundy od 1.1. 2000. Pokud bychom počítali, zjistili bychom, že 32-bitový formát by v tomto případě přestal stačit 11. srpna roku 2013 v 0:38 světového času. Pokud si uvědomíme, že NASA se sondou komunikovala vždy jednou týdně a poslední spojení přišlo 8. srpna letošního roku, je příčina nasnadě. Následovala poměrně očekávaná událost- automatický restart řídícího počítače. Ten ale dostal opět stejné údaje a tak se restart znovu opakoval. Sonda tím pádem ztratila orientaci – nemělo ji co řídit. Anténa mířící k Zemi najednou mířila jinam a stejné to bylo i se solárními panely. Následkem toho se rychle vyčerpaly baterie a ze sondy se stalo mrtvé těleso.
Na druhou stranu ovšem můžeme tuhle „chybu“ inženýrům vyčítat jen těžko. Vždyť Deep impact měla jen jeden hlavní úkol – bombardovat projektilem jádro komety Tempel-1. Tím pádem měla odejít do zaslouženého důchodu už v roce 2005, tedy dlouho předtím, než by někoho mohl 32-bitový formát pálit. Všechno, co sonda Deep impact udělala po své hlavní misi bylo už jen navíc.
Každopádně nám ale tyto dva nedávné příklady ukazují, že lety do vesmíru nejsou „běžnou rutinou“, jak se nám někdy může zdát. I inženýři, kteří staví rakety, kosmické lodě a sondy jsou jen lidé, kteří mají právo chybovat. I přes několikanásobné kontroly a testování se na něco prostě přijít prakticky nedá. Proto pokaždé, když do kosmu startuje nějaký nový aparát, cítíme zvláštní svíravý pocit, který nám říká – snad se všechno podařilo otestovat správně.
Zdroje informací:
http://forum.kosmonautix.cz/
http://dsl.sk/
http://dsl.sk/
http://forum.kosmonautix.cz/
http://www.kosmo.cz/
Zdroje obrázků:
http://blog.extreme-advice.com/wp-content/uploads/2013/01/error.png
http://www.americaspace.com/wp-content/uploads/2013/03/Cygnus_ISS_Docking-500×307.png
http://iss.jaxa.jp/en/kibo/about/images/iss_kibo.jpg
http://i.space.com/images/i/000/000/553/i02/h_esa_deepimpact_art_02.jpg?1291648816
Pravda pravdoucí. Ale přijde mi, že na takovýto typ chyb jsou náchylné hlavně počítače, nebo obecně automaty schopné reagovat pouze na předprogramované situace. Být tyto sondy pilotované, tak by přítomný kosmonaut takovéto chyby byl skoro jistě schopen odchytit a opravit. A je to, podle mne, jeden z důvodů, proč nenechávat vše na automatech a proč je třeba rozvíjet pilotovanou kosmonautiku a to právě do vzdáleností, kde je dálkové řízení nějakého automatu problematické.
Na druhou stranu pilotovaná výprava je mnohem náročnější, komplikovanější a logicky i dražší. Ve většině případů se hodí levnější sondy, které jsou sice náchylnější k poruchám, ale dají se v případě ztráty nějak nahradit (vypuštěním nové, podobné) sondy, než stavět pilotovanou loď, která by byla dražší než několik „postradatelných“ sond.
Nic to ovšem nemění na faktu, že pilotovaná kosmonautika je důležitá – např. http://exospace.cz/potrebujeme-jeste-nasa/, http://exospace.cz/pripomenuti-jiz-44-let-na-mesici/.
Fakt skvěle napsané. Díky za podrobné popis obou chyb.. V tom shonu jsem minulý víkend ani nevěděl, co se v obou případech stalo. Rád to odkážu v pondělním článku 🙂
Díky za pochvalu i za odkaz. 🙂
Veľmi pútavé a zaujímavé čítatnie – na takýto článok som sa dlho tešil (študujem totiž informatiku a akosi takéto članky na pomedzí astronomia/informatika chýbajú)
Sú to také pikošky s ktorými môžeme „strašiť“ začínajúcich programátorov (aj samých seba) – na akých detailoch môže stáť úspech celého programu
Ešte raz vďaka 🙂
Díky moc za pochvalu. Máte pravdu, že zprávy z tohoto poměrně úzce profilovaného oboru nejsou prezentovány často. Ono to bude částečně tím, že pokud mise běží jak má, tak tyto aspekty zůstávají (zcela logicky) abych tak řekl „za oponou“. Na světlo se vytáhnou teprve až když je nějaký problém (a naštěstí jich nebývá mnoho).
Na druhou stranu tím, že se o takových tématech píše jen zřídka, je to pro nás, coby autory, trochu náročné. Za sebe mohu říct, že jsem byl při psaní článku tak trochu nesvůj. Nejsem totiž studovaný informatik a bál jsem se ,abych nechtíc neudělal nějaký „kopanec“. 🙂
Áno, je to tak ako hovoríte. Našťastie sú ale ľudia, ktorí aspoň trochu vidia „za oponu“ a vďaka týmmto článkom čiastočne aj my, laici 🙂
Myslím, že tu nejde o nejaké podrobné technické správy a vlastne aj celý blog sa celkom úspešne snaží o popularizáciu astronómi do takej miery, aby tomu rozumel aj celkom náhodný čitateľ.
Chápem vašu neistotu – ale je to znak toho, že vám skutočne záleží na dobrom článku. Len smelo ďalej – ranking článku hovorí sám za seba 😉
Dominik, Prešov
Díky, hodnocení mne opravdu těší. Vážím si i Vašich pochvalných slov na adresu blogu. Děkuji za sebe i za všechny ostatní autory.
Díky za článek. Nějak mě těch sofwarových chyb přijde až moc. A navíc to jsou prakticky učebnicové chyby, za které by vás rychle vyhodili nejen od zkoušky, ale z libovolné soukromé firmy. Třeba špatná konverze typů u prvního Arian 5 která měla za následek pěkný ohňostroj. I zde popsané chyby se opět týkají formátu dat.
Skoro bych drze řekl, že je štěstí, že ti programátoři neprogramují software pro jadernou elektrárnu, ale „jenom“ pro kosmickou techniku.
Víte, v kosmonautice možná víc než kde jinde platí, že všechno má svou cenu. I v kosmonautice jsou různě odstupňované kvality. Třeba pilotovaná kosmonautika je jednoznačně lépe zabezpečená než ta nepilotovaná – všechno se tam testuje mnohem, ale opravdu mnohem podrobněji. Jde o to, že když má systém spolehlivost 90% a zainvestuje se do zkoušek (plácnu) deset milionů dolarů, tak se spolehlivost zvýší na 99%. Jenže čím má být stroj spolehlivější, tím gigantičtější investice musí přijít. Např. pro náš modelový případ by zvýšení spolehlivosti na 99,9% mohlo stát třeba padesát milionů – pětkrát víc, než původní testy, které zvýšily spolehlivost o celých 10%. Čísla jsem si vymyslel, ale jde o princip. Výroba kosmických sond je drahá. Pokud by se měly testovat ještě více, aby byly ještě spolehlivější, bylo by to nesmírně drahé. A proto se razí cesta, kdy se testuje důkladně, to ano, ale ne nad rámec smysluplnosti, kdy další testy zvyšují spolehlivost jen nepatrně, ale cena roste raketově. když to hodně přeženu, tak za cenu jedné superspolehlivě otestované sondy by mohlo být pět otestovaných normálně. Jak jsem ale řekl, něco jiného je u pilotované kosmonautiky – tam se opravdu testuje až na krev – podobně jako ve Vámi zmíněných jaderných elektrárnách.
A mimochodem, NASA je mezi všemi kosmickými agenturami vyhlášená právě tím, jak moc se věnuje pozemním zkouškám. Třeba takové Rusko by se mohlo učit.
Já tuhle pohádku o čím dál dražších testech na vylepšení spolehlivosti znám. Většinou je za tím ohromná byrokracie, celé testovací týmy manažerů, analytiků a testerů, komplexní software na monitoring a vyhodnocování testování. A většinou nikdo z těch zůčastněných lidí nakonec neumí ani programovat ani neví, jak funguje „raketový motor“ (hardware), a jejich jedinou motivací je mít za spoustu peněz včas ve všech kolonkách zelené OK.
A samotnej původní kód bastlí nějakej nevyspalej student na živnostňák pro firmu X, ta to dělá pro firmu Y a tu si najímá někod z „vekých“ firem typu IBM a podobných.
Věřte mi, opakované chyby v převodech formátů a podobné „drobnosti“ odpovídají spíše zatlučení senzoru do konektoru vzůru nohama kladivem než čemukoli jinému.
Mne sa ten popis chyby na Cygnuse nejako nepozdáva.
1. problém:
Formát z roku 1980 používa 10 bitov na počet týždňov. Každých 1024 týždňov (19,6 rokov) sa začína rátať od nuly. V roku 1999 sa začalo znovu rátať od začiatku. Ak teda idem v systéme z roku 1980, musím poznať poradové číslo cyklu alebo aspoň približne svoj aktuálny dátum, aby som mohol určiť v ktorom cykle sa nachádzam a ak to mali spravené dobre, tak za žiadnych okolností si Cygnus nemohla myslieť, že dostáva údaje z roku 1994, keďže musím vedieť, že 0 bola v roku 1999 a akúkoľvek hodnotu dostanem, tak ju môžem k roku 1999 iba pripočítať.
2. problém:
Ak by bola pravda, že formát z roku 1999 začína rátať od roku 1999 posunutý o 1024 týždňov, tak by oba formáty mali dávať presne rovnaké hodnoty, keďže formát z roku 1980 sa tiež po 1024 týždňoch vynuluje a teda sa dostávame do rovnakého problému ako v 1. probléme.
V skutočnosti podľa wikipédie však oba formáty majú rovnaký začiatok v roku 1980 a rozdiel je len v tom počte bitov (čo mne osobne aj dáva väčší zmysel). Pravdepodobnejšie teda je, že ak teda čakám 10 bitov a dostanem 13, tak vezmem prvých 10 a dostanem nezmyselné číslo a tie tri zostávajúce bity buď zahodím alebo mi pretečú do ostatných hodnôt kde narobia bordel. Každopádne mi v tomto prípade pripočítavanie 1024 nijako nepomôže a oprava bola z iného súdka.
Ešte raz som to prečítal a už som pochopil kde je chyba v článku:
Citujem: „Jeden totiž začíná s číslováním v roce 1980 (10-bit), druhý v roce 1999 (13-bit).“
a potom v ďalšej vete je „…Cygnus očekával údaje s referenčním rokem 1980.“
Čiže som na základe týchto dvoch viet predpokladal, že Cygnus ide v 10-bit formáte.
V skutočnosti 13-bit začína v roku 1980 a 10-bit vďaka preklopeniu do druhého cyklu začína v roku 1999.
SIGI teda vysiela 10-bit a Cygnus pracuje s 13-bit a teda preto si Cygnus môže myslieť, že dostáva data z roku 1994 a aj oprava pripočítaním 1024 sedí.