Otázka je, jestli s obyčejnými procesory uspějí i při několikaměsíčním letu k Marsu. Tam bude elektronika vystavena vysokoenergetickým částicím mnohem déle. Podle mě pro Mars misi už budou muset jít cestou radiačně odolných procesorů.

Zajímalo by mě, co se z tohoto hlediska osazovalo do Voyager 2

"Jako operační systém využívají stroje SpaceX operační systém Linux" To je pro běžné uživatel Windows dost matoucí formulace. "Lepší by bylo napsat, že používají ověřený otevřený kód operačního systému postavený kolem jádra Linuxu. Stejně tak je zavádějící náznak, že by se k tvorbě základního SW mohl použít jiný programovací jazyk než C nebo C++.

A proč by nemohl ?

Zaujalo mě, že mají povolenu dynamickou alokaci paměti, byť se ji snaží nepoužívat. Při práci na leteckých komponentách jsem se setkal s tím, že do certifikovaného přístroje žádná dynamická paměť nesměla, všechno se muselo alokovat staticky předem. Plus pěkně na papíře prokázat, že se to tam vleze i v nejhorším případě.

Jenze typicky komunikacni stack bez dynamicke alokace udelat nejde. Muzu udelat to, ze jde o dynamickou alokaci v ramci staticky alokovanych prvku (bufferu) predem urcenych k tomuto ucelu, ale uplne bez toho to nejde.

Jinak receno se lze vyhnout dynamicke alokaci z klasicke haldy (new/malloc), ale samotnemu principu ne.

V okamziku, kdy tam nejaka komunikace je tak navic musim dokazovat, ze jeji zahlceni a vycerpani pameti neohrozi ty chranene funkce systemu.

V Cechach moc lidi co se tim zabyva neni. Letecke komponenty = Honeywell v Brne, nebo neco jineho?

50 let starý programovací jazyk, který vznikl v době, kdy se šetřilo každým bajtem. Osobně mu říkám "prasečí jazyk", protože má všechny parametry naštvaného prasete, pobíhajícího v chlívku. Jedinou jeho výhodou je výkon, za který zaplatíte (doslova) obrovskými investicemi do ladění.

C++ neni 50 let staré. Jen 40 :) A C++ z roku 1979 vypadá o dos jinak, než C++17 (aktuální verze standardu).

Jako fajn, ale bude tohle číst někdo jiný než programátor?

Tady jste na Technetu. Jestli chcete nějaké lehčí čtení, doporučuji rubriky Revue a Hobby.

Vemi zajímavý článek. Osobně jsem čekal, že tam budou mít nějaké robustní staré procesory jako 486 a podobně. Doba pokročila.

Co je na 486 robusního? Ten je leda starý, tedy léty prověřený. Ovšem výkonově beznadějné subtilní. :-)

NASA je zvykla na stary zpusob psani kodu - requirements, navrh, kodovani, testovani. Problem je, ze mnohokrat nejsou pozadavky dobre definovane a nebo se v prubehu zmeni. Tyto pozadavky se totiz pisou na zacatku projektu, kde treba neni vubec jiste kam projekt presne povede. Zazil jsem, ze system splnil vsechny pozadavky, ale nefungoval spravne. Mimochodem pro critical flight SW se pocita 1 hodina na jednu radku kodu (vcetne testovani).

Nejen NASA. Občas jsou důsledky možné chyby takové, že si nikdo nevezme na triko nějaké "urychlení" nebo "optimalizaci" postupů. Nedávno jsem v části svého kódu s asi deseti tisíci příkazy změnil na základě zkušeností z mnohaletého provozu a požadavků uživatelů jednu konstantu. Už měsíce to běží na testovacích mašinách s reálnými daty a ještě měsíce to tak poběží a potisknou se stohy papíru, než se to dostane do "ostrého" provozu. Tedy ne 1 hodina na řádek, ale 1 rok (a desítky tisíc Kč) na jedno číslo. A to nejde o nějakou novou raketu, ale staré jaderné zařízení.

Delší dobu jsem byl contributor a maintaner OpenVSP (NASA parametric aircraft geometry tool) balíčku pro jednu distribuci, resp. první, hned jak to vydali jako OSS. A musím říci, že to bylo celkem peklo to nějak udržovat. Takže za mně mohu říci, že mně zase přijde přístup NASA trochu překvapující :). Ale chápu, že to není žádný kritický sw.

Zdar Max