Jak Češi staví a programují mezinárodní kosmické sondy?

Pár týdnů nazpět jste u mě měli možnost položit dotazy na to, jak se staví (po softwarové stránce) kosmické sondy, jmenovitě sonda Solar Orbiter. A nyní přišly odpovědi od Huld.

Na čem se Huld podílel na softwaru Solar Orbiter? (Vědátor)

Podílíme se na tzv. CSW (Centrální Software). To je software, který koordinuje ostatní subsystémy sondy (vědecké instrumenty, interní & externí komunikaci, navigaci, pohon, úložiště dat, distribuci energie atd.) a snaží se uchovat sondu v bezpečí skrze autonomii (např. zajišťuje neustálou orientaci sondy slunečním štítem směrem ke slunci, aby radiace a vysoko-energetické částice nepoškodili její citlivé části).

Jak vypadá reálně spolupráce ESA a česko-finské firmy? Kde a jak začala? (Vědátor)

ESA vypisuje své projekty a firmy se o ně pak uchází vypracováním návrhového dokumentu, kde je rozpracován předběžný design, cena, harmonogram atp. ESA pak ve výběrovém řízení vybere vítěze a ten na zakázce začne pracovat. Ty opravdu velké projekty (jako např. Solar Orbiter) jsou mimo možnosti i naší středně velké firmy, a tak je běžně vyhrávají společnosti vetší (v případě Solar Orbiteru zakázku vyhrál Airbus Defense &Space) a ty pak zpravidla odvedou vetší část práce sami, ale některé samostatně uchopitelné části dále delegují na menší firmy v odvětví. Často se pak také děje (jako v mém případě), že větší firma naopak najme od menších firem kvalifikované pracovníky po dobu implementace projektu. Tak či tak se peníze vybrané od daňových poplatníků členských státu ESA vždycky drtivou většinou vrátí do průmyslu oněch členských států.

Naše česká pobočka vznikla před téměř pěti lety ve snaze pracovat na více vesmírných projektech přímo v Česku.

Jak dlouho probíhala vaše práce na softwaru Solar Orbiteru? Jde o zakončenou zakázku, nebo stále probíhá?  (Vědátor)

K projektu jsem se připojil před dvěma lety a v té době už aktivní vývoj na centrálním softwaru (a projektu Solar Orbiteru celkově) probíhal již nějakých šest až osm let. Projekt se překlenul z implementačních fází B, C a D do své finální „letové“ fáze E, která zahrnuje ladění, implementaci posledních „maličkostí“ a přípravu na podporu mise (schopnost rychle a efektivně řešit potencionální problémy za letu). Krátký anglický souhrn těchto fází vesmírných misí lze nalézt zde:
https://www.esa.int/Science_Exploration/Space_Science/How_a_mission_is_chosen

V jakém jazyce je software napsaný? Na jakém operační systemu to běží? Je možné nějakým způsobem udělat vzdálený update? Je celý software napsaný inhouse nebo používá nějaké 3rd party libky nebo frameworky? (Vašek T.)

Tenhle konkrétní software je napsaný v čistém Ansi C (žádné objektové C++). Drtivá většina těchto safetycritical softwarů je napsána v nějakém nízko úrovňovém jazyce jako Ansi C nebo Ada, jelikož to umožňuje důslednější kontrolu nad pamětí a exekucí (vyšší spolehlivost) a hlubší optimalizaci (vyšší rychlost / efektivita). Pro některé speciálně důležité malé části se pak často využije i assembler.

Dá se říci, že centrální software samotný je operačním systémem sám o sobě. Zpravidla vždy existuje tzv. boot software, který je velmi malý, robustní a schopný plnit ty nejzákladnější funkce pro případ nouze (komunikace, přístup do paměti, diagnostika, testy). Pokud je vše, jak má být, tak vždy po restartu boot software zkontroluje elementární funkčnost a předá autonomně řízení mnohem většímu a složitějšímu centrálnímu software.

Na oba tyto softwary lze pohlížet jako na operační systém: běží v paměti jako jediné programy, přímo ovládají hardware a uživatel ze Země s nimi komunikuje podle předepsaných pravidel. Centrální software je pak jako operační systém mnohem vyspělejší (poskytuje vyšší funckionalitu), např. srze něj lze uložit na plavidlo procedury (tzv. On-boardprocedures) napsané speciálním jazykem, které lze podle potřeby autonomně spustit (např. nějaká kombinace monitorovaných parametrů dosáhne nepatřičných hodnot nebo specifické časy během mise, …). V případě Solar Orbiteruje tento jazyk celkemvyspělý, takže teoreticky lze např. napsat program který vypočte všechna prvočísla do tisíce, poslat ho centrálnímu softwaru do hlubokého vesmíru a nechat si zpátky na Zemi poslat výsledky. Samozřejmě reálně vykonávané procedury jsou užitečnější. 🙂

Co se týče aktualizace centrálního softwaru na dálku existují dvě hlavní možnosti: patch nebo celkový update softwaru. Pokud je potřeba v rozumném čase něco dodatečně upravit použije se patch a centrální software je na toto připraven (na patche existuje v paměti speciální místo a pokud sonda projde restartem a centrální software je znovu „neopatchovaný“ nahrán do paměti jsou patche opět aplikovány ve správném pořadí). Pokud by však patchů mělo být mnoho (nebo se beztak chystá nová verze centrálního softwaru) je bezpečnější zahodit dlouhý řetězec patchů a přehrát celý software. Celý nový softwarový obraz je samozřejmě nejprve pouze nahrán do paměti a zkontrolován a teprve poté se přistoupí na restart sondy (skrze zmíněný boot software)do nové verze centrálního softwaru.Ze Země lze změnit cokoliv co není zapsané do neměnných pamětí a systém je vysoce konfigurovatelný.

Drtivá část tohoto centrálního softwaru byla napsaná tady v Anglii pod střechou Airbus Defense &Space, ale vývoj některých částí byl delegován. Spoléháme na některé in-house napsané knihovny, které jsou znovu-užívány napříč projekty (např. matematická knihovna – netřeba pro každou novou misi psát znovu funkci, která bude bezpečně a rychle počítat odmocniny). Co se 3rd party produktů týče tak pro vývoj tohoto konkrétního centrálního softwaru je využit RTEMS ( https://en.wikipedia.org/wiki/RTEMS ), který hlavně poskytuje funkcionalitu pro multi-threading a synchronizaci. Pro potřeby testování, validace a verifikace je 3rd party produktů samozřejmě využíváno více.

Jak se resi redundance? Jake jsou postupy pro faulttolerantsystem? Pocita se s chybami na cpu vlivem radiace? Nakolik je systemautonomni co se tyka navigace a sberu dat? Pouziva se tam klasicky operacnisystem, nebo necovlastniho? FPGA? Co vsechno jde na systemuzmenit za provozu? Je mozne upravit zakladni sw za behu a na dalku? Jsou tam nejaka specifika okolo apijednotlivych sw modulu?

Redundance se řeší pro každý systém a jeho subsystémy individuálně (podle jejich předpokládané / modelované / naměřené výdrže) tak, aby systém jako celek vydržel s dostatečně vysokou mírou jistoty skrz celou hlavní misi (pro Solar Orbiter 7 let od startu). Někde je zapotřebí hot redundance jinde stačí coldredundace, ale v zásadě lze říct, že naprostá většina systémů je zdvojená (včetně všech jejich propojení, aby bylo možné nefunkční části „přemostit“). Redundance v paměti se zase řeší několika paměťovými bloky navíc, které v případě poruchy nahradí ty zrovna používané co se porouchaly.

Solar Orbiter byl vyhodnocen jako stupeň kritičnosti B (hned druhý nejvyšší pod stupněm A, kde už na správné funkci softwaru závisí lidské životy nebo jeho nefunkčnost může mít zásadní vliv na životní prostředí). To mimo jiné znamená, že sonda musí být schopná jakoukoliv první poruchu vyřešit autonomně (bez zásahu ze Země). Druhou a další následné poruchy (double fault) se autonomně pokusit opravit může, ale již není záruka, že sonda poté zůstane nadále plně funkční.

Sonda si stále musí být schopna do určité míry poradit v nesnázích sama bez jakýchkoliv příkazů ze Země. Její průměrná vzdálenost několika světelných minut nepředstavuje až tak velký problém jako fakt, že v závislosti na poloze Země může sondu její (heliocentrická) oběžná dráha na dlouhé týdny zavést „na druhou stranu“ Slunce, kam komunikace s ní není možná.

Její blízkost ke Slunci a silné radiaci samozřejmě představovala výzvu jak pro design hardwaru, tak pro design softwaru (design je v mnoha ohledech podobný nebo totožný se sondou BepiColombo, která byla před dvěma lety vyslána prozkoumat planetu slunci nejbližší – Merkur). Pro hardware to znamená odstínění kritických částí (které chybovost nezamezí, ale alespoň ji sníží), zdvojování / ztrojování výpočtů (paralelní – mám 3 identické jednotky; sériové – provedu ten samý výpočet 3x po sobě) a chytrý design (i to kudy a jak se vedou různé sběrnice může hrát roli).

Pro software je pak důležité být přípraven na to, že se vlivem gama paprsku jakákoliv nula může s určitou malou pravděpodobností změnit na jedničku (a jednička na nulu). Mezi hlavní způsoby, jak se tomuto bránit je využití kontrolních součtů na důležitá data (např. příkazy obdržené ze Země, vědecká a provozní data posílaná na Zemi, uložené procedury, konfigurační data, obrazy softwarů, …) pokud kontrolní součet na konci dat neodpovídá datům přijatým, operátor (nebo sonda) ví, že došlo k chybě v přenosu a že je třeba akci opakovat. Na ještě nižší úrovni v centrálním softwaru často existují tzv. scrubbing procesy, což jsou procesy s nízkou prioritou, které „ve volném čase“ neustále procházejí paměť od začátku do konce, čtou redundantní informaci uloženou na konci každého paměťového řádku a v případě dostatečně malého poškození používají nějaký samo-opravný kód pro obnovení původní informace. Často (zvlášť v dedikovaných paměťových jednotkách) přebírá úlohu těchto scrubbing procesů samotný hardware, takže centrální software má pak o starost méně a může se spolehnout na danou oblast paměti jako na regenerativní (do určité míry poškození).

Autonomie ve sběru dat je vysoká. Existují dva hlavní druhy dat posílané na Zemi: data provozní (stav sondy, vědeckých přístrojů a ostatního vybavení) avědecká (naměřená data z vědeckých instrumentů). Provozní data jsou generována neustále a jejich definovatelné podmnožiny jsou na Zemi odesílána v pravidelných definovatelných intervalech. Operátor může vždycky sondu požádat o jakákoliv provozní data mimo toto časování a sonda samotná dokáže posílat na Zemi tzv. události ať už běžné (započal plánovaný manévr) tak poruchové (porucha gyroskopu číslo 2). Vědecká data jsou generována vědeckými instrumenty, a protože jsou řádově vetší než data provozní, jsou zpravidla uchovávána ve velkých paměťových modulech odkud jsou na Zemi odesílána méně často než data provozní (ve vhodnou dobu). Vědecké instrumenty spolu také mohou komunikovat a „pomáhat si“. Např. když instrument na detekci gama záblesků detekuje velký záblesk pošle o tom broadcast zprávu a např. instrument na detekci nabitých částic ví, že brzo přijdou zajímavá data a může se na to připravit (vyšší snímkovací frekvence, jiný mód měření, …).

Centrální software pro Solar Orbiter (a safetycritical software obecně) se řídí přísnými pravidly. Např. žádná rekurze, velmi omezená alokace paměti, redundance, … V návrhu a implementaci softwarových rozhraní se to pak odráží dodržováním jasně definovaných striktních pravidel. Pár odkazů:
https://cs.wikipedia.org/wiki/MISRA_C
https://en.wikipedia.org/wiki/Safety-critical_system#Software_engineering_for_safety-critical_systems

Jak probihatestovani a simulace prostredi / chybovosti. Jak se testuji vstupy ze sensoru a zpracovanipredemneznamych dat? Jak se testuje redundance ruznych komponent pripadne jejich nahrazovani? (Lukáš K.)

Testování probíhá na několika úrovních oproti požadavkům té dané úrovně. Od unit testingu (úroveň kritičnosti Solar Orbiteru podmiňuje, že veškerý kód je třeba v unit testech kompletně pokrýt) až po validaci a verifikaci. Některé požadavky nelze testovat přímo a je třeba uchýlit se k inspekci nebo analýze.

Testing na všech úrovních obecně probíhá v samostatných modulech tzv. Software ValidationFacilities (SVFs). SVF může být téměř čistě hardwarová (Hardware SVF – HSVF), čistě softwarová (Numerical SVF – NSVF) nebo hybridní a vždy existuje způsob, jak do ní umístit testovaný software, jak ovládat toto prostředí (a tak například simulovat chyby z prostředí, které se zpropagují na vstup testovaného softwaru) a jak spouštět nad prostředím testové scénáře (aby se dala opakovaně spouštět předem připravená sada testů). V důsledku toho, že každá vesmírná mise do sluneční soustavy bývá svým designem unikátní prototyp, často i SVFs je potřeba vyvinout od začátku místo využití již existujících.

Redundance různých komponent se testuje právě v těchto SVFs. Pokud je SVF dostatečně vyvinutá lze např. simulovat,jak se software zachová, když současně přestanou fungovat některé dvě důležité komponenty. Centrální software komunikuje s okolím pomocí periodických zápisu do registrů a čtení z registrů, takže v čistě softwarových SVF stačí nasimulovat tuto komunikaci (což ovšem bývá někdy snad i složitější než vytvořit toto chování pomocí obdobných hardwarových komponent ze sondy).

Me by zajimal proces prenosu dat na tak velkevzdalenosti, jak je to s chybovosti siglau a jak je elektronika chranenapred vlivem prostredi? (Jiří Š.)

Sonda má pro komunikaci se Zemí k dispozici 3 koncové systémy: HGA (HighGainAntenna), MGA (Medium GainAntenna) a LGA (LowGainAntenna). U těchto antén platí, že čím nižší vyzářená energie, tím nižší frekvence, větší rozptyl, kratší dosah a lehčí míření směrem k Zemi. Tzn. LowGainAntenna je téměř všesměrová (ve skutečnosti pokrývá polovinu celého prostoru směrem od sondy, takže je na druhé straně další, která míří na druhou stranu), takže když je sonda zrovna blízko Země lze ji použít pro spolehlivou a relativně pomalou komunikaci (anténu netřeba nijak natáčet vzhledem k současné orientaci sondy a poloze Země). Naproti tomu HighGain Anténou je potřeba pečlivě mířit v obou osách (je méně všesměrová a více bodová), ale její vyšší frekvence poskytuje při stejné vzdálenosti vyšší přenosovou rychlost. Pro jednoduchost jsem vynechal komunikační sub-systém za těmito anténami (např. umožňující vybrat jednu anténu pro vysílání a jiné pro příjem; různé rychlosti příjmu atp.) a jeho redundanci.

Kolik mista (megabajtu) zabira soft na sonde, je tam misto na nejaky update, jak se data odesilaji a kolik dat prumerne v jedneodeslanevarce je? (Stanislav P.)

Boot software často zabírá řádově desítky kilo bajtů a centrální software desítky mega bajtů (tahle čísla se můžou lišit podle velikosti sondy / projektu, jelikož se od velikosti odráží množství toho, co všechno je třeba řídit).

Příkazy se k sondě zpravidla odesílají ve várkách a velikostí bývají o řád menší, než provozní telemetrie co se vrací zpátky (a o několik řádů menší, než telemetrie z vědeckých přístrojů). Výjimkou je třeba právě nahrávání nové verze softwaru, kdy jsou data naporcována do mnoha malých příkazů a ve várkách postupně nahrána na sondu. Některé malé příkazy zaberou pár desítek bajtů, jiné vetší teoreticky až pár kilo bajtů. Jsou využívány protokoly v mnoha ohledech principiálně podobné ISO/OSI (ale jednodušší v méně vrstvách).

Jak probíhá validace/verifikace kódu? (Standa F.)

Validace a verifikace probíhá podle přísných pravidel oproti softwarovým požadavkům (v požadavcích se odráží veškerá funkcionalita softwaru a mohou mít formu jak funkční, tak třeba výkonnostní nebo viditelnosti dat). Spolu s validací a verifikací nezávislým týmem uvnitř společnosti téměř vždy dochází ještě k tzv. ISVV (Independent Software Validation and Verification), kdy validaci a verifikaci provádí zároveň tým z jiné nezávislé společnosti, aby se ještě účinněji předešlo přenášení zaujatosti. Zjištění ze všech těchto aktivit jsou pak oficiálně zaznamenány a adresovány původním implementačním týmem. Validace a verifikace probíhá na výše zmíněných SVFs.

[odpovídal David Pejřimovský]

Vědátor vzniká v dílně spolku studentů a popularizátorů vědy UP Crowd za podpory MUDRstart, který tvoří přípravné testy pro studenty vysokých škol. Krom různých autorů projekt jako šéfredaktor vede Ladislav Loukota – jeho kontaktní mail je vedatororg@seznam.cz

Diskuze

Reklama