ElonX

Software a počítače, které pohánějí Crew Dragon, Falcony a Starlink (2. část)

Autor · Publikováno · Aktualizováno

V první části našeho článku o softwaru a počítačích, které SpaceX využívá ve své vesmírné technice, jsme si posvítili na Crew Dragon a Falcon 9 a také principy redundance. V druhé části se zaměříme na používané programovací jazyky, operační systém a také metody, kterými SpaceX svůj software testuje. Na konci pak najdete techničtější shrnutí zajímavých poznatků a také video s českými titulky na podobnou tematiku.

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 dominuje 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 tomto jazyce 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ř. 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. Zároveň je to ale typický zdroj bugů. Pokud takzvaně „spadne“ aplikace, původ chyby můžete často vypátrat právě k tomuto mechanismu.

První stupeň Falconu 9 s číslem B1060 během výroby (Foto: SpaceX)

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.

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ž pak 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 ale 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. Pikantní na tom je, že tato hodnota nebyla ve skutečnosti pro let potřeba a sloužila jen pro kontrolu pozice rakety na rampě. Inženýři pro programování rakety 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 ale nemohlo pomoci proti chybné myšlence. Nutno dodat, že tato chyba mohla být snadno odhalena, pokud by se tento 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 však nestalo.

Raketě Ariane 5 se stala osudnou klasická programátorská chyba (Zdroj: ESA)

SpaceX si ale na testování softwaru velice zakládá. Každá úprava je důkladně prověřována v testech k tomu určených 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 deaktivace 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ů.

Obvzlášť 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 pak vedlo k vyšetřování, nutnosti opakovat misi a celkově velkému zdržení. Také by to poškodilo tehdy se teprve rodící důvěru NASA se SpaceX. Inženýři ale 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. Nutno dodat, že pro daného zodpovědného manažera NASA představovalo toto riskantní rozhodnutí velkou zodpovědnost, ale také velký krok směrem k důvěře.

Dragon během mise COTS-2. Málem letěl domů s nepořízenou. (Foto: NASA)

Dodejme, že nedostatek tohoto komplexního testování byl důvodem, proč byly problémy během testovací mise lodi Starliner společnosti Boeing odhaleny až na oběžné dráze. Nebudeme zde tyto problémy rozebírat, dodejme ale, že se NASA v nedávné telekonferenci k výsledkům vyhodnocení tohoto incidentu přiznala, že věnovala více personálu a času na dohled vývoje softwaru ve SpaceX. 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ý ve firmě Boeing. 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ému lodi Starliner. NASA také přiznala, ž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.

A co Starlink? Inženýři prozradili, že s každým startem satelitů pro tuto konstelaci vynáší Falcon 9 na orbitu víc než 4000 linuxových počítačů. To znamená, že jeden satelit má v sobě možná až 66 počítačů. V současné době stále probíhá vývoj softwaru, kdy jsou nové verze testovány přímo na orbitě vybranými satelity a pokud se osvědčí, jsou jimi aktualizovány všechny satelity. V této vývojové fázi také satelity Starlink generují 5 terabajtů (5000 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 svoji deorbitaci, pokud by ztratily spojení se Zemí.

Více než 4000 počítačů na jedné fotce z mise Starlink v1-1 (Foto: SpaceX)

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).

Další informace o softwaru, který SpaceX používá, najdete v tomto videu, které jsme před časem přeložili do češtiny:

Latest posts by Martin Krčma (see all)
Počet zobrazení článku: 4 761



Štítky:

Mohlo by se vám líbit...

Odebírat komentáře
Nastavit upozorňování na
guest

53 Komentáře
nejnovější
nejstarší nejlepší
Inline Feedbacks
Zobrazit všechny komentáře
wpdiscuz   wpDiscuz