Jak SpaceX vyvíjí, testuje a používá software pro Crew Dragon a Starlink

Přibližně před rokem na našem webu vyšly dva články (první a druhá část) pojednávající o softwaru a počítačích používaných ve strojích SpaceX. Od té doby uspořádali inženýři SpaceX na sociální síti Reddit další AMA (Ask Me Anything) a server Stack Overflow připravil sérii článků s rozhovory s vývojáři softwaru ze SpaceX. Tento článek tedy shrnuje nové informace, které jsme se dozvěděli.

Připomeňme, že SpaceX ve svých počítačích využívá procesory PowerPC a letový software je napsán v programovacím jazyce C++. Hlavní počítače běží na operačním systému Linux v režimu reálného času. Počítače jsou pro zajištění spolehlivosti redundantní. Letový software je založen na principu takzvaného kontrolního cyklu. Jde o donekonečna opakující se cyklus analýzy stavu – rozhodnutí jak pokračovat – vygenerování příkazů pro hardware lodi. Na začátku každého cyklu počítače načtou údaje ze senzorů a podřízených systémů, určí, v jakém se nachází stavu s ohledem na získaná data, minulé stavy, plán, příkazy řídícího střediska a další skutečnosti. Učiní rozhodnutí, jak pokračovat dále, a na jeho základě vygenerují příkazy pro podřízené systémy. Tento cyklus běží jak na hlavních letových počítačích, tak i na podřízených kontrolérech. V Dragonu vykonávají letové počítače tento cyklus desetkrát za sekundu, některé z podřízených kontrolérů řídící dynamické systémy pak padesátkrát za sekundu. Při psaní řídícího software dbají inženýři SpaceX na to, aby případné bugy či problémy nenarušily vykonávání tohoto cyklu a aby ten vždy doběhl včas. Jednotlivé subsystémy jsou také co nejvíce izolované, aby bug v softwaru jednoho z nich neovlivnil řízení jiného.

V nově vyšlých článcích jsme se dozvěděli více o způsobu testování softwaru ve SpaceX. Firma klade velký důraz na spolehlivost svého softwaru. Jedním z důležitých principů pro udržení kvality a spolehlivosti softwaru je systém vzájemné kontroly. Když inženýr provede nějakou změnu či opravu, je povinen ji důkladně otestovat. Následně musí požádat jednoho ze svých kolegů, aby změnu posoudil a zkontroloval jak výsledky testů, tak i metodiku provedeného testování. Teprve poté se změna může zařadit do hlavní větve kódu. Zde pak intenzivní testování pokračuje. A autor změny je stále zodpovědný za to, že i tyto testy dopadnou úspěšně. Toto je v souladu s firemním principem „zodpovědné osoby“, kde je daný inženýr zodpovědný za přidělený problém od začátku do konce a očekává se, že jej bude proaktivně řešit ve všech jeho fázích. Nemůže si tak nad něčím obrazně umýt ruce s tím, že to předal jinému oddělení. Tento princip se netýká samozřejmě jen vývoje softwaru, ale i všech ostatních činností.

Během testování se nejprve provádějí jednoduché a rychlé testy pro odhalení základních chyb a regresní testy (obrazně řečeno, že změna nerozbila něco, co předtím fungovalo). Následují čím dál náročnější testy včetně komplexních simulací. Simulují se různé scénáře včetně částí reálných misí a někdy i celé mise. Například se tedy simulují i mnohahodinové mise Dragonu od startu na Falconu 9 až po dokování u ISS. Aby mohlo být testování opravdu intenzivní, provádí SpaceX simulace v softwarovém prostředí jak na počítačích vývojářů, tak ve svém stále se rozšiřujícím datacentru. Firma však nespoléhá jen na software, naopak provádí mnoho testů na skutečném hardwaru. Jde o princip HITL – „hardware in the loop“ (hardware v testovacím cyklu) vyslovované „hittles“ ve firemní hantýrce. Jedná se o testovací stanoviště, jež využívají skutečnou avioniku z Falconů, Dragonů a Starship, včetně letových počítačů, podřízených kontrolérů a senzorů. Zde je možné testovat reálné chování celého systému, simulovat mise a všemožné poruchy a selhání. Robustnost systému je testována například tím, že jsou náhodně vypínány různé kontroléry, senzory a počítače, aby se tak nasimulovalo jejich selhání, a sleduje se reakce systému na takové situace. Testovací stanoviště Crew Dragonu je vybavené dokonce systémem naklánění sedadel, takže inženýři fyzicky vidí, jak jejich software s astronauty hýbe.

Zajímavostí také je, že tvorby testů se účastní nejen vývojáři softwaru, ale i inženýři z ostatních oblastí, například z oddělení pohonů. To je jeden z důvodů, proč se pro psaní testů používá skriptovací jazyk Python. Jde totiž o přívětivý jazyk, který se dá rychle naučit a je tak vhodný právě pro ty inženýry, kteří nejsou součástí softwarového týmu, ale potřebují tvořit testy pro systémy, na nichž pracují.

Po dokončení testů probíhá verifikace, tedy ověření, že software odpovídá specifikacím, modelům a prototypům. Prototypy softwaru jsou rovněž psány v Pythonu. Rychlost vývoje nových funkcí je díky tomu vysoká a jakmile jsou s novou funkcí inženýři spokojeni, přepíšou ji do jazyka C++, v němž je implementován letový software. Během verifikace je tak možné porovnávat výsledky softwaru vůči jeho prototypu.

Řídící software rovněž ukládá učiněná rozhodnutí do telemetrie. To inženýrům umožňuje monitorovat chování softwaru jak během vývoje a testování, tak i během ostrého provozu. Mohou se tak ujistit, že se software chová dle předpokladů. Telemetrie se generuje každých 20 až 100 milisekund a jedná se o proud párů „klíč-hodnota“, kde klíč identifikuje konkrétní veličinu (tj. obrazně například tlak v kabině ze „senzoru 1“), jejíž hodnota je v páru obsažena. Může také jít o výsledky různých algoritmů a výpočtů, stavové informace a další veličiny generované softwarem. Dokud je loď či raketa na zemi, je telemetrie přenášena přes drátové spojení. Při letu se využívají různé přenosové kanály a přenáší se jen vybraná podmnožina telemetrie. Celá telemetrie se však ukládá pro pozdější analýzu po návratu na Zemi.

Po mnoho let se telemetrie přenášela v surovém stavu, nezašifrovaná. V březnu letošního roku se radioamatérům podařilo zachytit telemetrii z druhého stupně Falconu 9. Ze surových dat dokázali dekódovat (kódování a šifrování jsou dva různé procesy) čistý text nesoucí informace z GPS systému stupně. Později se dalšímu podařilo dekódovat i video, které stupeň automaticky posílal na Zemi. Na videu je vidět motor druhého stupně, náklad tvořený satelity Starlink a vnitřek nádrže na kapalný kyslík. S největší pravděpodobností nebyli první, kterým se to podařilo, ale mediální publicita, kterou si jejich kousek získal, se zřejmě SpaceX nelíbila. Ku nelibosti radioamatérské komunity začala firma proto brzy poté přenos šifrovat. Zklamaní byli i ti, kteří se nemohli dočkat odposlechu telemetrie ze startu Starship. Její přenosy byly následně také zašifrovány.

Svá hardwarová testovací stanoviště mají samozřejmě také družice Starlink. Nejedná se o nic jiného než skutečné satelity odebrané přímo z produkční linky. K tomu má SpaceX testovací model pozemní stanice a uživatelských terminálů, s jejichž pomocí může testovat systém komunikace a po úpravě softwaru i simulovat přelety satelitů nad stanicí. Nemohou tak ale testovat směrování signálů. Tyto testy inženýři dělají v simulovaném softwarovém prostředí. K testování se používají rovněž i vybrané satelity na oběžné dráze. To umožňuje sledovat, jak se nová verze softwaru chová v reálném provozu předtím, než je odeslána do celé konstelace.

Starlink pro komunikaci s uživatelskými terminály využívá fázové antény, signály komunikace s pozemními stanicemi jsou však směrovány mechanicky. Kvůli počtu uživatelských terminálů by je mechanické směrování nedokázalo dostatečně rychle obsluhovat. Pozemních stanic je ale samozřejmě méně a k výrazným změnám směrování dochází méně často. V případě uživatelských terminálů však dochází ke změnám směrování každých pár minut, což je důvod, proč jsou také vybaveny fázovými anténami. Satelity Starlinku se totiž pohybují natolik rychle, že s každým uživatelským terminálem komunikují jen několik minut, než se dostanou mimo dosah. Terminály se tak každou chvíli musejí přepojit na jiný satelit. Díky fázovým anténám je však přepojování velice rychlé a pro uživatele prakticky nerozeznatelné. Během přepojování se datový provoz terminálu ukládá do vyrovnávací paměti, aby se zvnějšku zachovala plynulost přenosu dat. Podle inženýrů je problém přenosu dat uživatelům poměrně náročný, a to nejen kvůli dynamice systému. Satelity totiž musejí vysílat na různých frekvencích, aby předešly rušení během obsluhy různých zákazníků. A vzhledem k tomu, že se to musí řešit v reálném čase a na celém světě zároveň, jde již jen z pohledu kombinatoriky o poměrně zajímavou výzvu.

Jednotlivé satelity, pozemní stanice i uživatelské terminály průběžně sledují dostupnost aktualizací a ve vhodnou chvíli je aplikují tak, aby to mělo co nejmenší vliv na uživatelský provoz. Vždy si zachovávají oddělenou kopii poslední funkční verze softwaru. Pokud by během aktualizace došlo k problému, dané zařízení se automaticky vrátí k uložené verzi. Nutno podotknout, že při těchto operacích dochází k aktualizaci softwaru na mnoha různých počítačích, z nichž se satelity i ostatní zařízení skládají (jeden satelit Starlink nese možná přes 60 počítačů). Aktualizaci stahuje centrální uzel a následně dohlíží na správný průběh aktualizace v ostatních systémech. Nové aktualizace vycházejí přibližně jednou týdně.

V druhé části tohoto článku se dozvíte podrobnosti o uživatelských rozhraních pro Crew Dragon a Starship a také spoustu dalších zajímavostí, které se jinam nevešly.

Předchozí články o softwaru ve SpaceX:

• Jaký software SpaceX používá a jak se vypořádává s kosmickým zářením?
• Software a počítače, které pohánějí Crew Dragon, Falcony a Starlink (1. část)
• Software a počítače, které pohánějí Crew Dragon, Falcony a Starlink (2. část)