Vědecký přístroj pro teleskop Euclid, který by měl měřit rychlosti vzdalujících se galaxií zrovna procházel zkouškami v podmínkách podobných kosmickému prostředí, když najednou přestal pracovat. Pro vědecký tým to bylo nečekané překvapení a všichni už měli v hlavách černé scénáře, ve kterých bude hledání příčin trvat týdny či měsíce. Nově zformovaný tým experů z ESA, tzv. tiger team proto přispěchal na pomoc a dokázal přesně odhalit příčinu. Podařilo se tak udržet harmonogram projektu Euclid v rámci povolené tolerance, aby se stihly všechny činnosti plánované před startem. Euclid bude kosmický teleskop studující temné složky vesmíru – temnou energii a temnou hmotu. Během své šestileté mise, kdy se bude pohybovat zhruba 1,5 milionu kilometrů od Země, bude s pomocí svého dalekohledu o průměru 1,2 metru mapovat trojrozměrné rozložení galaxií v prostoru až do vzdálenosti 10 miliard světelných let, což je zhruba třetina pozorovatelného vesmíru. Odhalením velkoformátových kosmických struktur a schématu rozpínání by měla mise odhalit tajemství temné energie a temné hmoty, které tvoří většinu vesmíru.
Zdroj: https://www.esa.int/
Aby bylo možné dosáhnout těchto odvážných cílů, bude Euclid potřebovat dvojici vědeckých přístrojů, na jejichž návrhu pracovalo téměř tisíc vědců ze 13 evropských států sdružených v konsorciu Euclid a zapomínat bychom neměli ani na účast agentury NASA. Kamera využívající viditelné světlo má spolupracovat se spektrometrem a fotometrem pracujícím v blízké infračervené oblast (NISP). Tento přístroj rozděluje infračervené záření přicházející z pozorovaných galaxií, aby z něj vyčetl údaje o jejich rychlosti. Měří tedy takzvaný rudý posuv na velmi podobném principu, jaký využívá třeba policie při radarovém měření rychlosti aut.
Zdroj: https://www.esa.int/
A o co šlo ve zmíněném problému? Zničeho nic během zkoušek se zbytkem modulu užitečného zařízení teleskopu Euclid v chladném vakuu přestal NISP pracovat. Paolo Strada, přístrojový inženýr programu Euclid vysvětluje: „Anomálie se objevila na letovém exempláři přístroje, který už byl jednou plně otestován, formálně přijat a následně integrován do modulu užitečného nákladu společně se všemi dalšími prvky jako je teleskop, kamera či optická lavice.“ Koncem května zahájil modul s užitečným nákladem termálně-vakuové testy ve zkušební komoře v Centre Spatial de Liège v Belgii, když NISP začal selhávat při začátku druhé fáze snímkovacích testů po dokončení první fáze.
Zdroj: https://www.esa.int/
„Představte si, že máte krásný digitální fotoaparát. Pořídíte s ním fotku, která vypadá dobře a chcete si udělat další. Ale když se o to pokusíte, tak ovládání foťáku najednou nereaguje. Nemůžete nastavit expozici nebo zmáčknout spoušť. Jediná možnost k pořízení dalšího snímku je restart, ale poté co to uděláte a pořídíte novou fotku se problém objeví znovu,“ popisuje Paolo Strada. Opakované restarty u teleskopu Euclid nepřichází kvůli jeho extrémnímu pozorovacímu úkolu v úvahu. Euclid má totiž každý den posílat na Zemi 850 gigabitů dat, což v průběhu celé mise udělá několik petabytů.
„Bylo to něco, s čím jsme se nikdy předtím nesetkali,“ vzpomíná Strada a pokračuje: „Přístroj NISP si vedl fantasticky během stovek hodin bezchybného provozu, bez jediného problému přenesl stovky terabytů. Zdálo se, že problém souvisí s kryogenními teplotami, kterým byl v komoře vystaven a za pokojové teploty se problém neprojevoval. Ale při zkoumání jsme měli svázané ruce, protože NISP a zbytek modulu užitečného nákladu byly uvnitř termálně-vakuové komory. Mezitím totiž stále pokračovala nominální testovací kampaň. Bylo to téměř, jako by mise už byla ve vesmíru. Dočasně jsme byli omezeni pouze na informace, které jsme mohli získat z telemetrie.“
Zdroj: https://www.esa.int/
Konsorcium členů průmyslových partnerů a expertů ESA z týmu Euclid bylo najednou téměř bezradné. Podezření se sice točilo kolem kabelů, které přenášely data z ohniskové roviny senzorů přístroje NISP do jeho počítače, ale konkrétní příčinu nikdo neznal. Možná byl původcem šum v signálu, možná elektromagnetické rušení odjinud a v úvahu připadalo i špatné uzemnění kabeláže. Zkrátka a dobře rozsah možných příčin byl tak široký, že tým zodpovědný za misi začal zvažovat druhou fázi vyhrazených termálně-vakuových testů, která by měla za úkol odhalit příčinu. To by však do našlapaného harmonogramu příprav vrazilo klín v podobě týdnů až měsíců zpoždění. Taková změna by se dozajista odrazila v termínu startu.
Zdroj: https://www.esa.int/
Než však bylo přistoupeno k takto drastickému řešení, byl zformován Tiger team expertů z ESA i průmyslových firem, kteří se měli pokusit o vyřešení záhady. Jedním z členů týmu byl Felix Siegle, z oddělení ESA pro palubní počítače a práci s daty. Právě on poznal, že zastavení provozu mělo svůj původ v softwarové chybě a nikoliv ve fyzické závadě. „Pročítal jsem si dokumentaci, mluvil s inženýry, uplatnil své znalosti a pak jsem začal být trochu podezřívavý. Pokud by ta závada byla opravdu čistě fyzické povahy, pak bych očekával, že porucha bude přerušovaná, ale místo toho docházelo k zamrzání pokaždé.“
Siegle se proto zaměřil na software, ve kterém se může přenos dat překrývat s ovládáním přístroje. Kromě vlastní analýzy doporučil týmu kolem projektu Euclid, aby se na tyto oblasti také zaměřili. A hledání přineslo kýžené ovoce. Ukázalo se, že chybový příznak, který by za normálních podmínek neměl představovat žádný problém, byl softwarem nesprávně interpretován jako signál, že došlo k poruše rozhraní telemetrie a řízení se senzory přístroje, což způsobilo jeho vypnutí.
Zdroj: https://www.esa.int/
„Příznak chyby se dříve neobjevil, protože konfigurace kabelu se oproti předchozím testům velmi mírně posunula, čímž se změnila doba šíření signálu ze senzorů do počítačového rozhraní,“ vysvětlil Siegle a doplnil: „Kryogenní teploty hrály také svou roli, protože vytvořily nepatrně delší latenci. Trefili jsme se tak do okna potřebného k posunu sotva o pár miliardtin sekundy. Výsledný příznak měl ve skutečnosti spíše informativní charakter. Nebylo to něco, na co by měl software reagovat, ale po identifikaci bylo možné toto nežádoucí chování opravit jednoduchou softwarovou záplatou. Odnášíme si tedy zkušenost, že při práci s takto složitým softwarem je dobré se podívat na oblasti rozhraní mezi hardwarem a softwarem, na práci různých společností nebo inženýrů. Právě v těchto meziprostorech může snadno dojít k nedorozumění nebo chybě.“
Zdroj: https://www.esa.int/
Stradu i zbytek týmu nesmírně potěšilo, jak rychle se podařilo najít řešení. „Felix mi během půl hodiny zavolal, že si myslí, že něco našel. Ukazuje to, jak je důležité podívat se na problém z jiného úhlu.“ Euclid tak zůstává na původním harmonogramu – nyní se již v sídle Thales Alenia Space v Turíně chystá spojení modulu užitečného nákladu se základním (servisním) modulem. Dalším krokem budou zkoušky celého teleskopu, které mají představovat poslední fázi testů před startem na raketě Sojuz. Ta by měla vzlétnout z kosmodromu v Kourou, přičemž startovní okno se otevře koncem roku 2022.
Přeloženo z:
https://www.esa.int/
Zdroje obrázků:
https://www.esa.int/…/2019/09/euclid_spacecraft/19709644-1-eng-GB/Euclid_spacecraft.jpg
https://www.esa.int/…/22401874-1-eng-GB/Instruments_installed_on_Euclid_spacecraft.jpg
https://www.esa.int/…/euclid_s_nisp_instrument/22125390-1-eng-GB/Euclid_s_NISP_instrument.jpg
https://www.esa.int/…/thermal_vacuum_chamber/23480958-1-eng-GB/Thermal_vacuum_chamber.jpg
https://www.esa.int/…/checking_telemetry/23480914-1-eng-GB/Checking_telemetry.jpg
https://www.esa.int/…/09/nisp_instrument/23481090-1-eng-GB/NISP_instrument.png
https://www.esa.int/…/23481002-1-eng-GB/Opening_chamber_after_testing.jpg
https://www.esa.int/…/euclid_spacecraft/23480327-1-eng-GB/Euclid_spacecraft.gif
Takže to vypadá, že i v případě odhalení problému až ve vesmíru by ho bylo možno vyřešit relativně jednoduše nahráním opravy software?
Pokud šlo o stejný problém, pak pravděpodobně ano.
Má se za to, že tento problém způsobovala „prodlužka“ mezi interními počítači v NISP a vnějšími počítači na Panelu servisního modulu (SVM). Při tomto testu totiž nebyl v komoře přítomný celý Servisní modul), ale pouze jeho část. Když se to řekne laicky, měli delší kabel a to už asi stačilo k výskytu problému s časováním. Byly to napínavé časy.
Zajimave na tom je, jak casto se proste rekne, ze za to muze chyba software. Hardware se pri nizkych teplotach zacal chovat jinak, nicmene tyto udaje nebyly k dispozici pri psani software, takze proste ten software na to nemuze byt pripraveny. Takze to neni tak uplne chyba v software, ale diky tomu, ze se da software updatovat (anebo prekonfigurovat), je mozne se vyporadat s drobnymi anebo vetsimi anomaliemi v hardware.
Podobna story byla v souvislosti se Schiaparelli crash landing. Casto se reportovalo, ze to byla chyba v software, ale pritom doslo ke dvema chybam v hardware, ktere podle specifikaci nemely nastat, a proto na ne flight software nebyl pripraven. Flight software se nepise tak, ze by nejaky softwarovy inzenyr premyslel „a co kdyby…?“, ale tak, ze ma presne pozadavky, vcetne na jake chyby ma reagovat. Naopak, software se analyzuje na existenci tzv. dead code (deactivated code/unreachable code). Zadny nadbytecny kod tam nema co delat anebo musi byt zajisteno, ze v zadnem pripade nemuze dojit k aktivaci (pomoci hardwarovych barier).
No, já jsem to tedy pochopil tak, že příznak, který měl být vyhodnocen jako informativní, vyhodnotil SW jako totální error, vyžadující shutdown a restart. A dřív se to neprojevilo, protože chování příznaku v konkrétním čase se netestovalo, neboť v předchozí konfiguraci příznak dorazil jindy. Jsem si celkem jistý, že zadání bylo „příznak vyhodnoť jako informativní“, určitě nebylo „v čase t1 až t2 vyhodnoť jako informativní, mimo tento čas to neřeš nebo to hoď do shutdownu“.
Tj. jde o chybu SW, na kterou se dříve nepřišlo vlivem neúplné analýzy – což řekněme si upřímně, je normální, žádná analýza není úplná.
Obecně je chování SW při chybách nejodfláknutější, protože se vždy primárně řeší, co to má správně dělat a pořádná analýza těch mimořádných stavů by zabrala řádově více času, než té funkční části.
Já bych se neodvážil říct, že chování SW při chybách je nejodfláknutější. Záleží jaký SW. U flight SW se tomu věnuje extrémně hodně pozornosti. Řekl bych spíš, ze je fault management prostě velmi komplikovaný a nedá se otestovat úplně všechno za všech podmínek. Analýza často nestačí; jakákoliv chyba, nepřesnost nebo neúplnost v dokumentaci může znamenat chybu v analýze. Vždycky je lepší test.
Jak jsem napsal výše, má se za to, že problém vznikl díky „prodlužce“ kabelu mezi NISP a vnějšími počítači (DPU). Při letu ve vesmíru prodlužka není, proto software nepotřeboval větší prodlevu ke komunikaci. Při bohatém testování na stole (i za nízkých provozních teplot) vše fungovalo, proto bylo překvapením pro všechny během testu, že NISP padá do SAFE modu. Podle informace z článku je překrytí signálu velmi malé, ale stačilo to k nestandardní situaci. Prodlužku už odstranili, prodloužení prodlevy by mělo zajistit dobrý provoz na oběžné dráze. Držme palce.
Děkuji za článek.
Díky, jsem rád, že se Vám líbil.