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:

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



Š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
ventYl

Mam skusenosti z pribuzneho odvetvia – tradicne automotive (teda nie samojazdiace systemy a multimedia) a vacsina z toho, co robi SpX sa robi aj tu. Navyse:

  • je natvrdo zakazana rekurzia. Hlbka (a velkost) zasobnika musi byt staticky vypocitatelna analyzerom a vsetky rekurzivne algoritmy musia byt prepisane na nerekurzivne varianty.
  • rovnako je natvrdo zakazana dynamicka alokacia pamate. Vsetka pamat je dopredu alokovana staticky na zaklade poziadavok algoritmov. Tomu sa podriaduje volba datovych struktur. Povacsinou su to polia a hashovacie tabulky.
  • neexistuje if bez else. Kazdy if musi mat else, aj keby bol prazdny. Takisto sa vzdy pod if a else vytvaraju bloky, aj keby bol vovnutri jediny prikaz. Toto je prevencia bezneho omylu, kedy sa zavesia 2 if-y za seba a potom sa da else. Z formatovania moze kod budit dojem, ze else patri k prvemu if-u, aj ked v skutocnosti parti k druhemu.
  • vyzaduju sa “yoda conditions”, teda pri porovnavani na rovnost sa vzdy prva pise konstanta a az potom premenna. cize typicky automotive kod vyzera if (TRESHOLD == sensorValue). Toto je staticka prevencia priradovania v podmienkach, ktora bezne vznikne ako preklep a je dost zaludna na objavenie.
  • nikde v kode sa nesmu pouzivat numericke konstanty ine nez 0. Vsetky numericke konstanty musia byt pomenovane
  • prakticky neexistuje preempcia. alokacia uloh je staticka, rovnako cely planovac uloh je nastaveny staticky a kazdy kod musi dobehnut v dopredu stanovenom casovom limite.

Z procesorov, ktore sa bezne pouzivaju su to PowerPC na miesta, kde je treba naozaj velky vypoctovy vykon, potom rozne exoticke RISCove architektury od vymyslu sveta, ktore sa pouzivaju prevazne kvoli nizkej spotrebe a optimalizacii na mizivu spotrebu v idle a miestami ARM, STM8 a mozno este aj Atmel AVR. Samojazdiace systemy a multimedalne centra casto pouzivaju bud vykonne ARMy alebo x86tky.

3
0
Odpovědět
jregent

Český Jablotron, což je podobný obor, také používá na řízení IoT komponent C++ a na testy Python

0
0
Odpovědět
Bystroushaak

neexistuje if bez else. Kazdy if musi mat else, aj keby bol prazdny. Takisto sa vzdy pod if a else vytvaraju bloky, aj keby bol vovnutri jediny prikaz. Toto je prevencia bezneho omylu, kedy sa zavesia 2 if-y za seba a potom sa da else. Z formatovania moze kod budit dojem, ze else patri k prvemu if-u, aj ked v skutocnosti parti k druhemu.

To je super divné, normálně se to řeší kontrolou linterem někde na build/test serveru.

0
0
Odpovědět
bohyn

To jestli mas else ke spravnymu ifu ti zadny lint nezkontroluje, jedine prave to, ze kazdy if ma else. Tudiz chapu tohle pravidlo, ale v praxi sem ho jeste nepotkal. Sam sem ale else u blbyho ifu videl. Bylo to u jednoradkovych if bez tela (kod pokracoval na stejnem radku jako if).

Naposledy upraveno před 4 lety uživatelem bohyn
2
0
Odpovědět
Bystroushaak

Můžeš kontrolovat jestli sedí indentace a jestli jsou za ifama chlupaté závorky a vynucovat je.

0
0
Odpovědět
Invc

Ono to není jen o té kontrole přiřazení ELSE ke správnému IF v kodu před kompilací… aby programátor neudělal chybu.

Jde o to, co ti z toho vyleze po průchodu compilerem Podle nastavení compileru (zejména úrovni povolených optimalizací) ti z toho může vylézt instrukčně rozdílný kod. (Instrukce navíc / jiné instrukce).

A ke všemu s tím rozdílným kodem, pak ještě může různě nakládat samotný procesor. (Další optimalizace / out of order execution / speculative execution / branching …).

Ve výsledku pak to můžeš mít velmi rozdílné, jak výpočetní náročností (přičemž neplatí, že více instrukcí musí nutně znamenat vyšší výpočetní náročnost – záleží co a nad jakými daty se dělá, jak konkrétně je to v daném compileru a procesoru řešeno).

(Nehledě na určité výhody při trasování / debugingu / reverseengineeringu přeloženého kodu – ale ono to je hodně provázáno s tím, co vlastně chceš dělat).

Z technického pohledu – to není vůbec zvláštní požadavek (jen je to trochu blíže hardware – než většina programátorů obvykle přemýšlí – respektive potřebuje brát ohled).

Naposledy upraveno před 4 lety uživatelem Invc
0
0
Odpovědět
ventyl

V tomto pripade je procesor vacsinou pomerne hard-core RISC (v zmysle, ze cely procesor je staticky, nie je v nom ziaden mikrokod, nie v tom zmysle, ze neobsahuje delicku), takze ziadne spekulacie ani optimalizacie sa nekonaju. Kod sa vykonava tak, ako je poslany do procesora. Obvody na speculative execution stoja energiu a software sa vyvija na mieru hardware-u, takze nie je potrebne za kazdu cenu ten kod uspesne spustit na kazdom podporovanom procesore.

Prekladace su sice vsivave az strach, ale pri optimalizacii si urobia dobru robotu. Tie prazdne branche tam nie je ani v najmensom vidno a debugovat release kod je spravidla dost dobrodruzna zalezitost.

1
0
Odpovědět
bohyn

Mas pravdu, na rizeni dlasich microkontroleru potrbujes determisticky urcit cas pro zpracovani vlastnich hodnot na vstupu (ze senzoru). Na tohle neni x86 vhodna, ta si upravuje instrukce jak se ji zlibi a obcas to casove okno nestihne, protoze se branch predictor seknul. V tomhle maj RISC procesosry vyhodu svoji “hlouposti”. Jo PowerPC ma taky out of order zpacovani, ale hloupejsi a ma kratsi pipeline a ty casy jsou predvidatelnejsi.

0
0
Odpovědět
bohyn

Netusim jak mi pomuze kontrola odsazeni kdyz mam

if(i == 1)
  do something;
if(i == 2)
  do sometinig;
else
  do else;

Jak ma lint poznat, ze ten else je uspravnyho ifu? Navic cune to “do something” napise na stjny radek jako if. Za to by se mely lamat prsty, ale v kodech to najdes.

Ty navic delas v pythonu, tam je odsazeni nutnost a chlupaty zavorky nejsou.

0
0
Odpovědět
Bystroushaak

Linter by tě měl upozornit, že ti tam chybí závorky. A jakmile je tam přidáš, tak je to jasné, ne?

0
0
Odpovědět
ventyl

To pravidlo pochadza niekde z dob Apolla, potom bolo prebrane armadou, adaptovane na C a potom prebrate automotive odvetvim niekedy v dobach drevnych, ked sa zacinali pocitace tlacit do aut a prestali byt programovane v assembleri. A uz to tak zostalo.

Mimo ine aj preto, ze az do pomerne nedavnej doby nieco ako build/test server neboli samozrejmostou.

1
0
Odpovědět
bohyn

Tak ze ma mit if telo se zavorkama, to je jasny, prazdny else to mi tak smysl nedava. Jak to ale vyresis v pythonu? Pridas do lintu pravidalo na radzny radek kolem if. To je ale celkem vhodne i s chlupatyma zavorkama, zlepsuje to citelnost.
Tohle a dalsi pravidla sem jednostranne zaved u nas ve firme a cekam, kdo zacne brecet. Zatim je to ve fazi merge reqestu, tak po zacleneni sem zvedavej.

Naposledy upraveno před 4 lety uživatelem bohyn
0
0
Odpovědět
Mário

Hmm tento článok a následná diskusia mi asi zničili sny na lepšiu budúcnosť. Som si vravel že sa chcem mať lepšie a musím preto niečo urobiť. Tak sa naučím programovať. Viem trochu niečo o PC a že sú programovacie jazyky a že ten zvyšok sa naučím. Ale mám pocit že to asi bude náročnejšie ako som si myslel. Čítam uvažujem čítam znova a nerozumiem. Ako by to už nebola čeština ale klingoncina 🙂 Toľko neznámych pojmov a vecí že mi ide hlava vybuchnúť a ajtak nechápem a pozerám ako tela.

0
0
Odpovědět
Petr Melechin

Učený z nebe nespadl. 🙂 A nikdy není pozdě začít se učit něčemu novému. Na internetu je spousta materiálů a kurzů zdarma, které vás seznámí se základy programování například.

1
0
Odpovědět
ventYl

SW vyvoj je odvetvie, ktore je dost vynimocne tym, ze prakticky nevyzaduje ucitelov. Studijnych materialov, ako teoretickych, tak praktickych prikladov, skutocnych projektov, otazok a odpovedi je na Internete tolko, ze jedine, co treba, su motivacia a cas. A tiez je dnes uz tak siroke, ze je prakticky nerealne snazit sa ho pokryt cele.

Kazdopadne bud zacat s Arduinom, alebo priamo s holym procesorom. S hrackami radovo za 10 eur sa da urobit “embedded hello world” rozblikanim LED diody a potom je to uz len o napadoch.

0
0
Odpovědět
Bystroushaak

Netřeba se lekat, dej tomu pár let a bude z tebe programátor. Jen je třeba si uvědomit, že to rozhodně není triviální záležitost a vyžaduje to určité odhodlání. Kdysi jsem sepsal něco na tohle téma tady: http://blog.rfox.eu/cz/Programovani/Jak_se_stat_programatorem.html

0
0
Odpovědět
berda

Arduino je hrozná prasárna. Ale chápu, že to může být nějaký začátek…

0
0
Odpovědět
ventyl

Ale je tam aspon ta mala vyhoda, ze clovek nie je postaveny pred velmi strmu uciacu krivku. To by mal v pripade, ze by si kupil AVRko, nepajive pole, programator a DC adapter a skusal rozblikat LEDku. Ono to ide, ale clovek musi byt tak nejako dost otrly, aby vyriesil tych par vela problemov, pred ktore bude postaveny, kym ta LEDka zacne blikat. Podla mna to je lepsia cesta, nez mat hotove Arduino, pretoze sa clovek viac nauci, ale nie kazdy je ochotny prejst si tymi strastami.

0
0
Odpovědět
setapouch

Děkuji za sérii dvou opravdu velmi zajímavých článků.
Zaujala mě například kombinace kódu v C++ a testů v Pythonu. Je toto běžné například i v korporátním prostředí, nebo je psaní testů v jiném jazyce než kód samotný něco méně obvyklého?

3
0
Odpovědět
Invc

Je to běžná věc.Každý jazyk má nějaká pro a proti a na něco se hodí více a na něco méně.
Tady ta volba je vcelku očekávatelná:

Letový HW: chceš kontrolu nad tím, co se tam PŘESNĚ děje a chceš, aby se to dělo pekelně rychle. (Přiřazování jader procesům si děláš ručně, používání cache, registrů, pamětí, I/O atd – chceš mít přesně pod kontrolou. Pro jejich účely a potřeby je i logická volba RISC procesorů – PowerPC / ARM). Takže potřebuješ jazyk, který ti umožní jít “blíže” k hardware … a tam C++ je vcelku první na ráně… jenže to je pomalejší na změny a náročnější na vývoj.

Testy naopak můžeš nechat jet na čemkoliv (děláš v podstatě “protikus” testovanému letovému hw/sw) – a jde ti o to, jen vystavovat data na rozhraní a sbírat reakce letového HW (a můžeš si tam dovolit klidně superpočítač – páč nikam nepoletí) – tam si můžeš klidně ušetřit práci, a tu “část blíže k hw” klidně nechat “na automatice (compiler / interpreter)… a jelikož tě netrápí hardware detaily, tak použiješ jazyk, který toho “půl udělá za tebe” a naopak ti umožní upravovat to téměř za pochodu.

Naposledy upraveno před 4 lety uživatelem Invc
15
0
Odpovědět
setapouch

Díky za info.

0
0
Odpovědět
bohyn

Dobre receno, na integracni/akceptacni testy neni potreba pouzivat stejny jazyk. Python ma vyhodu, ze pred spustenim neni potreba kompilovat (casove narocny proces treba u C++, Javy C# atd.).
Pokud by slo o unit testy (v podstate testovani radek po radku, ze se chova tak jak ma) je lepsi pouzit stejny jazyk, nebo aspon kompatibilni (moznost prolinkovat knihovny).
BTW, unit testy zaberou cca 50-75% casu, integracni a akcepacni jsou na tom lepe (to i bez ohledu na jazyk). Pak statistika NASA dopadne tak, ze programator v prumeru za jeden den napise 3 radky kodu 😉

3
0
Odpovědět
hotovson

jen bych doplnil, ze – a predevsim v projektech, jako dela SpaceX – je vhodne, aby tym, ktery pise testy, byl oddeleny od tymu, ktery se snazi temi testy projit

3
0
Odpovědět
ventYl

Je uplne bezne mixovat viacere jazyky podla toho, co sa na co hodi. S C++ mozno ziskat vysoky vykon, deterministicke chovanie a male naroky na pamat, ale vyvoj trva dlho. V Pythone sa daju napisat pomerne zaujimave veci za velmi kratku dobu, ale skor ci neskor to zacne byt dost pomale. To ale na beh testov nejako zasadne nevadi. Pri Pythone je navyse moznost niektore kriticke casti kodu, ktore beh spomaluju “vystrcit” do Ccka a tak ziskat spat cast rychlosti.

1
0
Odpovědět
Premek

Parádní článek, dikec!

5
0
Odpovědět
Jiří Hadač

Článku sice z části nerozumím, ale neznamená to, že není zajímavý. Je, líbí se mi 🙂 To víte, chemik, programátořiny sem nechal po střední.

5
0
Odpovědět
plegen

Což je úžasné. Mimo jiné jako IT technik v důchodů to dokážu posoudit. Že si SpaceX jako primární počítačovou architekturu zvolila 16ti bitové dvoujádrové procesory, shledávám jako geniální počin. A i výběr SW byl také velmi chytrý. NASA to také uznala. Teď fandové ruského Roskosmosu mohou prskat a dále pomlouvat E. Muska. Mohou to okopírovat, rychlejší je ukrást, stejně jako AB, jenomže jim to bude trvat děle ne 4 roky, protože se v tom neumí orientovat, nemají na to.

2
-7
Odpovědět
bohyn

SX pouýívá 64bit a možná i 32bit (PowerPC existují oboje) počítače.
Politiku si nechte od cesty 😉

Naposledy upraveno před 4 lety uživatelem bohyn
9
-1
Odpovědět
plegen

Ano, vaše politika.

1
-8
Odpovědět
Ivo Janáček

Jelikož jsem s PowerPC přišel fyzicky do kontaktu, tak bych vás rád upozornil na to, že tyto CPU byly zkraje 32 bitové, ale následně už 64 bitové. Nevím, kde jste vzal těch 16 bitů. Už i můj první počítač měl 32 bitový procesor a to už je sakra hodně dávno (30 let), co jsem si ho pořídil.

9
0
Odpovědět
plegen

Omlouvám se zdvořile. Pokud článek budete číst pečlivě, pak se to dozvíte. Architektura začíná na 16ti bitech, pokračuje na 32, možná dál na 64 bitech. Velkou roli hraje radiace uváděná v článku. To není nová skutečnost. Mám doma netebook, jede na 64 bitech a Windovsu 10. RAM 1 GB, HD 1 TB, s tímto HW, zejména s OS jsou jen problémy a zejména s aktualizaci MSW.
Mimochodem, první počítač jsem pořídil kolem roku 1991. Od té doby už nejméně 20. Sám jsem si je skládal dle svých preferencí, sám jsem instaloval OS od DOSu, přes Windows 3.1, až po Win 10.

1
-11
Odpovědět
bohyn

Asi nečteme stejný článek. Je tam pouze zmínka, že došlo k přetečení celého 16bit čísla, při konverze z desetinného. Bylo to u Ariane 5 a ten SW navíc pocházel už z Ariane 4. SpaceX začínala na x86 a přešli na PowerPC a ARM. Nikdy 16bit a možná ani 32bit neměla.

Naposledy upraveno před 4 lety uživatelem bohyn
9
0
Odpovědět
plegen

Čtu stejný článek a neporozuměl jste. Mně to nevadí. Složitost je pojem, kterou každý nemusí pochopit. Žijte dlouho a blaze.

1
-14
Odpovědět
bohyn

Bohužel se stále nechytám, znovu sem si předchozí článek přečet a žádná zmínka o znovupoužitelnosti, ani 16bit CPU tam není. Zkuste mi pomoci nějakou citací, nebo odkazem. Nebo taky můžete přiznat, že jste se seknul, to se stává.

5
0
Odpovědět
plegen

Omlouvám se všem čtenářům. Ano seknul jsem se. Mám takový dojem, že v článku byl uváděný procesor x86, což byly procesory Intel řady 80286, 80386 a 80486, které se už dávno nevyrábí. Po opětovném přečtení se tento údaj už nevyskytoval. Možná to byl jen můj dojem, Nechci nic tvrdit. SpaceX používá dvoujádrové a čtyřjádrové procesory starší výroby, zejména kvůli ceně, ale ty nemohou být 16ti bitové. V tomto uvažování mne ovlivnila i skutečnost, že miniaturizované polovodičové součástky jsou náchylné víc na radiaci.
 
V znovupoužitelnosti jsem se také mýlil. Není třeba znovu používat počítač zasažený masivnější, pro jistotu je lepší takový počítač, i vzhledem k nízkým pořizovacím nákladům, raději celý vyhodit.

1
0
Odpovědět
plegen

masivnější radiaci

0
0
Odpovědět
Petr Melechin

Architektura x86 opravdu byla v článku původně zmíněna, ale nejspíš se jednalo o chybu (respektive často propíraný, ale ničím nepodložený mýtus), a tak byl text upraven, jelikož nejspíš používají PowerPC. Řešili jsme to tady v diskuzi.

Každopádně poslední 16bitové procesory x86 byly pokud vím 80286 a jelikož SpaceX používá vícejádrové procesory, je jasné, že by stejně muselo jít o něco novějšího než 40 let staré 286. 🙂

2
0
Odpovědět
plegen

Jenom bych doplnil. Mikroprocesor 286 byl čistě 16ti bitový. 386 byla už 32 bitová, ale běžely na ní i 16ti bitové aplikace. To byl můj první PC,  Již měla matematický koprocesor. 486 byla již 32 bitová, ale běželi na ní i aplikace 16ti bytové. 486 také. Zpětně to ovšem neplatilo.

0
-4
Odpovědět
Jiří Hadač

V jednom televiznim poradu, tusim pod lampou se mi moc libilo, jak rozebirali ceny procesoru pro vesmirne sondy, vykonove sunka, za cenu desitek tisic dolaru, presne si to nepamatuju, ale bylo to dost zajimave 🙂

1
0
Odpovědět
ventYl

386 v ziadnom pripade matematicky koprocesor nemala ako samozrejmost. To sa tykalo len procesorov znacenych DX. Procesory SX mali orezanu adresnu zbernicu a nedisponovali koprocesorom. Aj tak sa mi zda, ze aj DX boli dodavane s koprocesorom v samostatnom puzdre.

Vzhladom k zavsivavenosti celej architektury x86 je nanajvys pravdepodobne, ze v 16bitovom realnom rezime tie procesory bootuju dodnes.

2
-1
Odpovědět
diwalt

Je to ještě trochu jinak. 386 DX a SX se lišily šířkou vnější sběrnice. Vnitřně byly oba procesory 32bitové, ale SX měla 16bitovou vnější sběrnice a DX 32bitovou. Koprocesor byl úplně samostatný chip 80387 a zdaleka ne každá deska na něj měla patici.

Až 486 měly integrovaný korpocesor a existovala verze DX s funkčním FPU a SX, která buď FPU neměla vůbec, nebo byl nefunkční a vypnutý. Ještě existovala verze i486GX, což byla verze 486SX (tj. bez FPU) s nízkou spotřebou a 16bitovou vnější sběrnicí (SX i DX jinak měly interní i externí sběrnici 32bitovou a lišily se přítomností FPU).

A v zásadě ano, 16bitový reálný režim procesory x86 nadále podporují a lze do něj přímo bootovat a provozovat 16bitové programy, ale dlužno dodat, že už nejde o úplně nativní režim, ale uvnitř CPU dochází k překladu instrukcí (koneckonců současné x86 procesory jsou vnitřně hybridní a s původními 80×86 mají málo společného). Dnešní desky s UEFI už ovšem v 16bitovém režimu nebootují a Intel už několikrát deklaroval, že podporu legacy BIOS v některé z blízkých generací ukončí.

2
0
Odpovědět
bohyn

Kooprocesor 487 se pro 486 dal koupit i zvlast. On to byl vlastne plnohodnotny 486DX a po osazeni odpojit SX procesor a nahradil veskerou jeho cinnost. U 386 to byl skutecne jen FPU.

2
0
Odpovědět
Sob

Ty jsi borec.

1
0
Odpovědět
Tomáš

Máte to špatně. U 16 napíšete “ti”, ale u 64 “ti” už ne 😀

0
0
Odpovědět
plegen

A zejména se jedná o náklady a znovupoužitelnost, to v článku taky zaznělo.

0
-4
Odpovědět
bohyn

Znovupoužitelnost není v článku ani jednou a jak to souvisí s procesorem?

2
0
Odpovědět
plegen

Znovupoužitelnost byla zmíněná v prvním díle. A pak kdo čte.

0
-2
Odpovědět
Laďa

Satelity jsou také naprogramované tak, aby automaticky zvýšily svůj aerodynamický odpor a urychlily tak svoji deorbitaci, pokud by ztratili spojení se Zemí. Ti sateliti 🙂

1
-2
Odpovědět
Petr Melechin

Opraveno. 🙂

5
-1
Odpovědět
plegen

Což obdivuji také. Člověk je tvor omylný. A sledovat pravidelnou rigiditu v pravopisu není zrovna produktivní (shoda podmětu s přísudkem), důležité je zachovat smysl sdělení. Smysl sdělení se nemění. Ale i přesto děkuji.

2
-6
Odpovědět
Jiří

Těch 5 TB dat (>3 GB/min) jsou opravdu jen telemetrická data? Takovou hodnotu bych čekal spíš u celkové přenosové kapacity jednoho satelitu.

1
0
Odpovědět
PetrK

Ony to asi nebudou jen telemetrická data, ale i logy aplikací. Nicméně berte to tak, že v reálném provozu to bude výrazně méně. V této fázi je nutné především analyzovat, takže to poběží v “debug” módu – loguje se v podstatě všechno, co lze.

3
0
Odpovědět
Tom

No, ne všechna telemetrie se musí posílat, třeba mají automatické filtry co je zajímavé a co se může hned smazat

2
0
Odpovědět
wpdiscuz   wpDiscuz