V první části našeho článku o softwaru a počítačích, které SpaceX využívá ve své vesmírné technice, jsme se věnovali především lodi Crew Dragon, nosiči Falcon 9 a také principu redundance.
V druhé části se zaměříme na používané programovací jazyky, operační systém a metody, kterými SpaceX svůj software testuje. Na konci najdete techničtější shrnutí zajímavých poznatků a také video s českými titulky k tomuto tématu.
Jako operační systém využívají stroje SpaceX operační systém Linux. Zatímco na osobních počítačích ve světě dominuje systém Windows, ve většině ostatních oblastí obvykle je právě Linux. Najdeme jej všude od síťových prvků, serverů, superpočítačů přes mobilní telefony a televize až po roboty a rakety. Výhodou tohoto systému je vysoká flexibilita a otevřenost, které umožňují vývojářům systém upravovat ku svým potřebám. SpaceX si například systém upravilo pro lepší odezvu pomocí režimu reálného času.
Palubní software Falconu 9 i Dragonu je napsán v programovacím jazyce C++. Jde o jeden z vůbec nejpoužívanějších jazyků, který se vyznačuje vysokým výkonem a univerzalitou. V tomto jazyce byl vyvinut nespočet aplikací a kromě strojů SpaceX je v něm napsán např. i software stíhačky Lockheed Martin F-35.
C++ je jazyk, který dává programátorovi poměrně hodně svobody, ale zároveň na něj kvůli tomu klade více zodpovědnosti za kvalitu kódu. Programátoři tedy musejí věnovat zvýšenou pozornost tomu, aby nevytvořili bugy.
Konkrétně ve SpaceX se tomu snaží předcházet například co nejmenším využíváním dynamické alokace paměti. To je mechanismus, skrze který aplikace může získat větší paměťový prostor pro své výpočty a po jejich ukončení jej vrátit zpět operačnímu systému. Díky tomu mohou mít aplikace tolik paměti, kolik potřebují, ale zároveň se tak operační paměť udržuje co nejméně obsazená a dostupná všem aplikacím. Je to však také typický zdroj bugů. Pokud takzvaně „spadne“ aplikace, původ chyby můžete často vypátrat k tomuto mechanismu.
První stupeň Falconu 9 s číslem B1060 během výroby
Další věcí, na kterou potřebují dávat pozor, je práce s tzv. datovými typy. Různá data v paměti počítače mají různé datové typy, které určují, kolik paměti zabírají, jaký mají formát, co je to vlastně za data (např. celé číslo, reálné číslo, text atd.) a jak se s nimi pracuje. Vhodná volba datových typů pro různá data a jejich korektní vzájemné převody (kdy např. potřebujeme z reálného čísla s desetinnou čárkou vyrobit číslo celé), jsou zásadní pro kvalitu kódu a je to opět typický zdroj chyb.
Co nadělá chyba
Své o tom vědí například programátoři rakety Ariane 5, kteří se nevyhnuli poměrně typické chybě při volbě a převodu datového typu jisté veličiny, což způsobilo destrukci rakety při jejím prvním letu v roce 1996.
Chybu udělali v tom, že převáděli hodnotu horizontálního zrychlení rakety vůči odpališti z původního datového typu 64bitového reálného čísla (který dokáže uchovat astronomicky vysoké číslo) na mnohem menší datový typ 16bitového celého čísla se znaménkem (který dokáže uchovat číslo o maximální hodnotě 32 767). V jistou chvíli však byla hodnota pro tak malý rozsah příliš velká, což vedlo k uložení chybné hodnoty a následně eskalovalo v pokus letového počítače o masivní korekci trajektorie a následnou katastrofu. Hodnota přitom nebyla ve skutečnosti pro let potřeba a sloužila jen pro kontrolu pozice rakety na rampě.
Inženýři při programování Ariane nevyužili C++, ale jazyk Ada. To je jazyk, který byl navržen tak, aby striktně hlídal programátorovu práci s datovými typy a předcházel bugům. To však nemohlo pomoci proti chybné myšlence. Nutno dodat, že tato chyba mohla být snadno odhalena, pokud by se systém (měřící ono zrychlení) zahrnul do testovacích simulací a kdyby se tyto testy prováděly s realistickými daty odpovídajícími vlastnostem nové rakety. Což se nestalo.
Prvnímu exempláři nosiče Ariane 5 se během jeho letu v roce 1996 stala osudnou klasická programátorská chyba.
SpaceX si na testování softwaru velice zakládá. Každá úprava je důkladně prověřována v testech k tomu určeným a v různých simulacích a celý systém je testován přímo na letovém hardwaru. Testovací týmy mají sestavenou kompletní síť počítačů a elektroniky celé rakety a lodě a testují na ní chování celého systému v průběhu celé doby mise. Simulují tak všechno od zahájení odpočtu až po vypuštění nákladu na orbitě, přistání prvního stupně a deaktivaci druhého.
Využívají k tomu reálná data z předchozích letů (z každé mise nasbírají stovky gigabajtů dat) stejně jako různé krajní scénáře. Během těchto simulací pak také náhodně vypínají různé počítače, aby simulovali jejich selhání, a pozorují, jak se s tím celý systém vyrovná. Tyto simulace neprovádějí jen během vývoje a před starty, ale i během misí, kdy do tohoto testovacího systému mohou přivádět reálnou telemetrii z rakety a lodě a monitorovat jeho chování. To jim může pomoci urychlit identifikaci a řešení případných problémů.
Obzvlášť u Dragonu se to hodí, jelikož mají možnost software na dálku upravit. Jen díky tomu mohla firma úspěšně dokončit svou úplně první misi k ISS (COTS-2). Při příletu k ISS byl tehdy navigační software Dragonu zmatený v důsledku neočekávaných světelných podmínek.
Velmi vážně hrozilo přerušení mise. To by vedlo k vyšetřování, nutnosti opakovat misi a celkově velkému zdržení a také by to poškodilo tehdy se teprve rodící důvěru NASA se SpaceX. Inženýři však byli přesvědčeni, že tento problém zvládnou vyřešit úpravou softwaru ze Země. Podařilo se jim přesvědčit i NASA, ta k tomu dala svolení a mise skončila úspěchem. Pro daného manažera z úřadu to bylo odvážné rozhodnutí, protože na sebe vzal značnou zodpovědnost.
Dragon během mise COTS-2. Málem letěl domů s nepořízenou.
Nedostatek takto komplexního testování byl také zřejmě důvodem, proč některé vady v pro SpaceX konkurenční lodi Starliner společnosti Boeing byly odhaleny až na oběžné dráze.
Jak NASA uvedla během nedávné telekonference k výsledkům vyhodnocení incidentu Starlineru, agentura věnovala větší pozornost (více personálu a času) dohledu nad vývojem softwaru ve společnosti SpaceX než v Boeingu. Muskova firma totiž používá pro NASA neobvyklý způsob vývoje softwaru, a tak v něj měla agentura nižší důvěru než v průmyslu tradiční způsob vývoje používaný u osvědčeného dodavatele. Důvěra ve zkušenosti Boeingu a zaměření dohledu primárně na SpaceX vedlo k nedostatečné kontrole výsledků Boeingu a následným problémům Starlineru.
NASA také uvedla, že se jí některé aspekty interních metod testování ve SpaceX a jejich metody dohledu na kvalitu software zalíbily a hodlá je prosazovat i ve svých projektech.
Tisíce počítačů při jednom startu
Samostatnou kapitolou je systém Starlink určený pro poskytování internetu z oběžné dráhy. Od inženýrů ve SpaceX jsme se dozvěděli, že při každém startu satelitů pro tuto konstelaci vynáší Falcon 9 na oběžnou dráhu víc než čtyři tisíce linuxových počítačů. To znamená, že jeden satelit má v sobě možná až 66 počítačů.
Drak zkrocený webovou stránkouSoftware je často přehlíženou stránkou současných kosmických lodí. V poslední době však programátoři a inženýři společnosti SpaceX alespoň trochu dali nahlédnout do nitra systémů, které řídí jejich stroje, včetně nové kosmické lodi pro lety s posádkou Crew Dragon. |
V současnosti stále probíhá vývoj softwaru, kdy jsou nové verze testovány přímo na orbitě vybranými satelity, pokud se osvědčí, jsou jimi aktualizovány všechny satelity. V této vývojové fázi satelity Starlink generují 5 terabajtů (5 000 GB) telemetrických dat denně.
Přenos uživatelských dat je zabezpečený pomocí šifrování. Samotné satelity i pozemní systémy mají hardware navržený tak, aby na něm mohl běžet jen software podepsaný SpaceX. Bezpečnost systému se neustále vyvíjí a zlepšuje.
Oproti Falconům a Dragonům nemají Starlinky v sobě mnoho redundance (ale nějakou ano). SpaceX spoléhá spíše na to, že mají k dispozici mnoho satelitů, takže jim případně mohou přidělit úkoly těch, které by snad měly poruchu. Satelity jsou také naprogramované tak, aby automaticky zvýšily svůj aerodynamický odpor a urychlily tak svůj pád do atmosféry a sebezničení, pokud by ztratily spojení se Zemí.
Výpis technologií a metod používaných ve SpaceX
- Letový software je napsaný v C++ a assembleru. Jsou využívány knihovny třetích stran, ale jen ty, které SpaceX vyhodnotilo jako mimořádně kvalitní (standardní knihovna, Das U-Boot, Buildroot, MUSL). Při programování se snaží vyhnout dynamické alokaci paměti. Využívají OOP a modulární návrh. Řídí se těmito pravidly pro psaní spolehlivého softwaru. Některá pravidla v seznamu samozřejmě ignorují, takže například neomezují délky funkcí na jednu tisknutelnou stránku.
- Rozhraní Crew Dragonu je napsáno v JavaScriptu, HTML a CSS a je vykreslováno jádrem prohlížeče Chromium. Mají vlastní React knihovnu. Displeje mají zabudované vlastní počítače založené na Nvidia Tegra (pravděpodobně verze 2).
- Falcon 9 a Dragon 1 využívají dvoujádrové procesory PowerPC a mikrokontroléry založené na PowerPC (pravděpodobně). Falcon nese nejméně 30 počítačů, Dragon 54. Crew Dragon využívá čtyřjádrové procesory PowerPC. Jde o běžně dostupné procesory (COTS), nikoliv radiačně chráněné.
- Falcony a Dragony využívají trojnásobnou redundanci počítačů a mikrokontrolérů. U letových počítačů běží letový software na všech jádrech, redundance je tedy dvojnásobná. Crew Dragon využívá tři počítače, každý s dvěma samostatnými procesory. Redundantní je i většina senzorů a akčních členů.
- Falcony a Dragony běží na Linuxu s patchem CONFIG_PREEMPT_RT a vlastními ovladači. Velkou pozornost věnovali scheduleru, který je v jednu chvíli pěkně potrápil. Aplikace se snaží dělat jednovláknové. Jádro je verze 3.2 (dva roky stará informace), ořezali z něj více než 80 % kódu. Distribuci mají vlastní.
- Většina kódu je (nyní) na misích stejná, provádějí se ale úpravy s ohledem na charakter mise, počasí, bezpečnostní limity apod.
- Dragon sdílí s Falconem mnoho kódu.
- Dragon používá navigaci podle hvězd a LIDAR.
- Počítače v řídící místnosti mise mají Windows + LabView. Podpůrné nástroje v C# a dalších technologiích.
- Testy v Pythonu.
- Testy se provádějí přímo na letovém hardware s reálnou telemetrií, kdy se simuluje mise od začátku do konce.
- Starlink má end-to-end šifrování, satelity i pozemní hardware můžou spouštět pouze podepsaný software. Bezpečnost se neustále rozvíjí.
- Ovládací rozhraní Starlinku hodně vychází z rozhraní Crew Dragonu.
- Pro Starlink vyvíjejí vlastní ASICy (zákaznické integrované obvody).
Konec druhé a závěrečné části. První díl najdete zde.
Článek byl převzat z webu ElonX.cz, před vydáním byl redakčně upraven. Originál najdete zde.
U následujícího videa si lze zapnout i české titulky.
