Język programowania używany w kosmosie

Cześć, który nowoczesny język programowania jest coraz częściej stosowany w przemyśle kosmicznym? Według tej dyskusji jest to język C++, wspomagany Pythonem. I czym jest ten "Integrity" os. Nowy system kosmiczny całkowicie pisany w C++ zamiast C?
https://www.reddit.com/r/space/comments/4y50sj/which_programming_languages_are_used_by_nasa/

Urządzenia w których bardzo ważny jest czas reakcji są obsługiwane przez systemy operacyjne czasu rzeczywistego (RTOS): https://pl.wikipedia.org/wiki/System_operacyjny_czasu_rzeczywistego

Same programy pisze się pewnie w bardzo dziwaczny sposób, by uniknąć czegokolwiek co ma niedeterministyczną wydajność - np dynamicznej alokacji pamięci.

Na tej stronie w NASA cały czas przewijają się dwa języki, tj Python i C++.
https://code.nasa.gov

No i ścisłe reguły pisania, to w zasadzie niezależne od języka, tu jest akurat dla C:
http://www.rankred.com/nasa-coding-rules/
http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf

Javascript? :D

TR-3B napisał(a):

Na tej stronie w NASA cały czas przewijają się dwa języki, tj Python i C++.
https://code.nasa.gov

Moim zdaniem jakieś 99% kodu napisanego w NASA nie siedzi w rakietach kosmicznych, tylko jest odpalane na serwerach na Ziemi i te 99% kodu robi różnego rodzaju symulacje, analizy, etc które nie mają silnych wymagań co do czasu reakcji - tzn jeśli analiza potrwa 5 sekund dłużej niż szacowano to nic się nie stanie. W rakiecie kosmicznej opóźnienie rzędu jednej milisekundy może być kosztowne.

Obecnym standardem dla systemów RT jest C, czasem C++, w obu przypadkach z dodatkowymi obostrzeniami typu MISRA albo odpowiednie normy. Do tego często specyficzny hardware, np.
http://www.ti.com/lit/wp/spry180/spry180.pdf

Zależy jeszcze co rozumieć przez "kosmos". Na przykład do systemów krytycznych przy zastosowaniach wojskowych, czy lotnictwie to język ADA. W tym pisze Lockheed Martin, Boeing i inne koncerny lotnicze/wojskowe. To w końcu też są zastosowania kosmiczne, tylko w celach innych niż badawcze :). Pytanie tylko na ile to jest nowoczesny język i na ile w ogóle używa się nowoczesnych języków do takich systemów.

1. Flight software to nadal głównie ADA, szczególnie do krytycznych systemów.
2. Cała reszta random, ale z naciskiem na C/C++, Python, Java.

Zresztą co za problem sprawdzić:

• Flight Software -> https://www.space-careers.com/jobsearch/view_25741.html
• Flight Software -> https://www.space-careers.com/jobsearch/view_25925.html
• Ground Software -> https://www.space-careers.com/jobsearch/view_25822.html
• Ground Software -> https://www.space-careers.com/jobsearch/view_23441.html

SpaceX pisze w C++ flight software, reszta random o ile dobrze pamiętam.

Myślę, że wybór języków w NASA jest też trochę ograniczony przez dostępność odpowiednich programistów na rynku. Misje NASA mają bardzo długi czas trwania. Dwa lata temu musieli znaleźć kogoś do prac nad oprogramowaniem dla sond Voyager 1 i 2 z lat 70. i wymaganiem była znajomość starożytnych asemblerów oraz Fortrana :). A wszystko przez to, że ostatni programista z oryginalnej ekipy tego programu zamierzał odejść na emeryturę, tymczasem sondy jeszcze przez co najmniej kilka lat będą aktywne.

Jak mieli ogarniętych programistów to już dawno wszystko jest w pythonie/javie lub ogólnie wysokopoziomowe, co to za problem mieć assemblerowe operacje jako obiektowe, to tylko kilka bajtów zapisanych binarnie?

W ogóle ja nie rozumiem jak @Shalom właśnie ty, chcesz ryzykować własne życie, utratę mięśni itp. tylko dlatego żeby latać sobie w kosmos?
Tam nie ma grawitacji, to prawie jakby się zajmować fizyką kwantową, makroskopową, ale reszty nie rozumiem.
Chodź sam zawsze chciałem latać to czy zupa fasolowa w kosmosie jest jak silnik odrzutowy :D

@zyxist to jest bardziej kwestia kosztów i testowania. Szczególnie jeśli chodzi o hardware, ale software też. Wydaje sie miliony na testy naziemne, bo jak już coś poleci to nie bardzo jest jak to naprawić. Stąd na przykład wiele sond/satelitów lata na archaicznych komputerach a mechanikę projektowano 20 lat temu. Nie dlatego że nie mamy dzis nic lepszego, tylko dlatego że to juz latało i jest sprawdzone.
Nowoczesne języki jak Java czy Python nie są projektowane z myślą o krytycznych systemach i o bezpieczeństwie, stąd też średnio się nadają. Zresztą do real-time/embedded też jak pięść do oka, więc flight software w tym nie będzie. Amerykanie mieli taki genialny pomysł chyba z F-35, żeby pisać soft w C++ zamiast w Adzie, ze względu na to że jest więcej programistów. I nie wyszło im to za dobrze...

@Shalom: czemu zawsze opuszczasz ze mną konwersację?
Wiem, że chcesz być astronautą, też chciałem zawsze latać.
Wiem wszystko o tobie.

alagner napisał(a):

Obecnym standardem dla systemów RT jest C, czasem C++, w obu przypadkach z dodatkowymi obostrzeniami typu MISRA albo odpowiednie normy. Do tego często specyficzny hardware, np.
http://www.ti.com/lit/wp/spry180/spry180.pdf

Systemy czasu rzeczywistego to jedno, systemy bezpiecznie to co innego.
Można napisać spokojnie w C system który będzie odpowiadał w określonym czasie. Gorzej ze stabilnością.

A tak w ogóle, to 8 lat temu dyskutowano o tym na SO, na razie nie zauważyłem tu nic nowego:
https://stackoverflow.com/questions/243387/which-languages-are-used-for-safety-critical-software

Odpowiedź odnośnie JPL i NASA:
http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

Dodatkowo również :
https://en.wikipedia.org/wiki/MISRA_C

MISRA jest m.in. używana w niektórych projektach i eksperymentach w CERNie. Zespół w którym pracuję ze względów na certyfikację bibliotek dotyczących protokołu komunikacyjnego przy miernikach promieniowania, również rozważał budowę własnego standardu w oparciu o MISRA właśnie.

@Shalom - zgadzam się, że testowanie takiego sprzętu to poważna sprawa :). Jeśli chodzi o "archaiczność", wskazałbym trochę inne przyczyny, z których najważniejsze to zasilanie oraz warunki pracy. Sonda New Horizons była budowana w latach 2001-2006, a główny komputer pokładowy ma procesor Mongoose-V taktowany zegarem 12 MHz. Zasilanie sondy to 1 RTG, który musi zasilić nie tylko komputer, ale także wszystkie instrumenty, ogrzewanie i w ogóle wszystko. A jego moc z czasem maleje. Po drugie - sonda nie musi wykonywać ciężkich analiz danych (może poza autonomiczną nawigacją). Jej główne zadanie to skierować w odpowiednim momencie odpowiednie przyrządy na odpowiedni obiekt, nagrać ciąg bitów i wysłać go na Ziemię.

Po drugie - sonda nie musi wykonywać ciężkich analiz danych (może poza autonomiczną nawigacją). Jej główne zadanie to skierować w odpowiednim momencie odpowiednie przyrządy na odpowiedni obiekt, nagrać ciąg bitów i wysłać go na Ziemię.

Ciężkich analiz nie, ale ma wystarczająco dużo "do roboty". Z racji ograniczonego zasilania i ograniczonej masy statki kosmiczne mają spore limity na rozmiar i możliwości anten. Generalnie szybkość transmisji danych jest mocno ograniczona, a telemetrii do wysłania bardzo dużo. W efekcie między innymi stosuje się różne metody kompresji danych, żeby dało sie ich upakować jak najwięcej. Więc ten ciąg bitów, który leci na ziemie to moze być punkt na wielomianie interpolacyjnym, który wymaga jeszcze odpowiedniej kalibracji, a to wszystko żeby zaoszczędzić kilka bitów i upchnąć dane z kolejnego sensora.
Z zasilaniem dla CPU to bym nie przesadzał, bo mamy dużo bardziej ekonomiczne układy niż kiedyś ;)
Z archaicznością jest też taka kwestia że od czasu kiedy się coś "projektuje" do czasu kiedy to poleci mija sporo czasu a ze zmianami w projekcie ciężko. ATV zaczęto projektować w 1998 roku, pierwszy poleciał w roku 2008 a ostatni w 2014, a to i tak lajtowa sytuacja bo one leciały tylko na niską orbitę, a nie musiały lecieć do celu długi czas. Takie BepiColombo zaczęto projektować w 2009 roku, poleci w 2018 a u celu będzie dopiero w 2025 :)

W każdym razie dopóki C rządzi w kosmonautyce nie namówicie mnie na lot na Marsa.

@vpiotr a który język Cię przekona? ;)

alagner napisał(a):

@vpiotr a który język Cię przekona? ;)

Takiego jeszcze nie ma.

Musiałby być:

• szybki jak C
• bezpieczny jak Rust
• elastyczny jak Lisp
• czytelny i obiektowy jak Java
• odporny na awarie jak COBOL (który potrafi podzielić przez 0) czy Ada (która ma pre- i post-conditions)
• cukierkowy jak Python czy Nim

Dopisałbym tu Smalltalk, Scale, Kotlin czy Go gdybym je znał.
Może jakbym dogonił C++17 czy C++20 to bym coś w tym języku dopisał na tej liście.

Taki język powinien być nie tylko bezpieczny, ale też umożliwiać pisanie wysokopoziomowych abstrakcji, żeby nie powiedzieć użytkowego AI (które na statku powinno być wg mnie nawet w... czajniku). No i nie powinien mieć przestojów (żadne tam GC) i oszczędzać zasilanie (efektywny).
Powinien też umożliwiać bez zająknięcia wysoką precyzję (sorry double, idź do konta).
O automatycznym kompilowaniu na GPU nie wspomnę, ale mam nadzieję że ten kierunek (OpenACC) się utrzyma.

Patrząc na listę wymagań @vpiotr wychodzi na to, że softem sterującym statkami kosmicznym powinien być kopiczek.

@vpiotr:

• szybki jak C
  […]
• czytelny […] jak Java
  […]
• cukierkowy jak Python czy Nim

Zdecyduj się.

Co do podanych wymagań, to Rust ma najbliżej:

• szybkość porównywalna z C (jakby to język był "szybki" lub "wolny")
• nie jest homoikoniczny, ale makra i rozszerzenia kompilatora (to 2. na razie tylko w nightly) dają Ci całkiem dużą swobodę
• nie wiem co przez to rozumiesz, ale IMHO obiektowość w wydaniu Javy to nie jest wzór do naśladowania, podejście Rusta z traitsami zdecydowanie bardziej IMHO pasuje
• ktoś kiedyś zrobił bibliotekę do Rusta oferującą pre- i post-conditions ale wymaga sporej aktualizacji, jednak jest to jak najbardziej możliwe (nie wiem czy w stable, ale w nightly na 100%). Co do dzielenia przez zero możesz stworzyć własny typ, który nie będzie mógł przechowywać 0 lub będzie obsługiwał dzielenie przez 0 w sposób jaki chcesz. Nie jest wcale to trudne, a typechecker załatwi resztę za Ciebie.
• Proszę nie… nie cierpię składni przez wcięcia w Pythonie

@hauleth: Dlaczego każesz mi się zdecydować? Nie chcę i nie muszę! ;-)
A pre- i post-conditions - to byłby mocny dodatek do wielu języków, nie rozumiem dlaczego jest tak mało popularny.

Rust może i jest porównywalny z C ale nie szybszy.

Czy język sam w sobie może być szybszy lub wolniejszy? Oczywiście że tak. Wątpić w to mogą tylko ludzie którzy wierzą w notację big-O.

Ale już jakiś czas temu udowodniono że jest przeceniana. Coś na temat:

• https://dzone.com/articles/c-benchmark-%E2%80%93-stdvector-vs
  Na YT jest też prezentacja potwierdzająca to co twierdzi Bjarne Stroustrup - "And, yes, my recomendation is to use std::vector by default" - niestety teraz nie mogę znaleźć linka.

vpiotr napisał(a):

Musiałby być:

• szybki jak C
• bezpieczny jak Rust
• elastyczny jak Lisp
• czytelny i obiektowy jak Java
• odporny na awarie jak COBOL (który potrafi podzielić przez 0) czy Ada (która ma pre- i post-conditions)
• cukierkowy jak Python czy Nim

• zwięzły jak Haskell
• łatwy w pisaniu jak Scala (btw uważam, że Scala jest trudna w czytaniu - pisze się łatwo).

No i żeby kompilował do FPGA jeszcze kawałki krytyczne, potem GPU i w ostateczności mało wpływające na szybkość rzeczy na CPU.

@vpiotr: bo wszyscy inni twórcy języków wyszli z założenia, że to tak na prawdę nic innego jak fikuśny zapis assercji.

Co do tego Benchmarks Game:

• Mówimy tu o zastosowaniach HRT a Benchmarks Game zdecydowanie odbiega od tych wymagań. Testują np. wydajność regexpów (regex-redux), których na 100% nie użyjesz w systemie HRT (a jak już, to tych z Rusta, niż PCRE, bo Rustowe używają DSM i nie obsługują powrotów, więc masz stałą liniową złożoność).
• W teorii nic nie stoi na przeszkodzie by Rust był przynajmniej tak szybki jak C (a ze względu na ograniczenia w języku, może być nawet szybszy), tylko C ma za sobą 45 lat optymalizacji, Rust 7 (jeśli liczymy od pierwszego publicznego wydania). Więc jak FE Rusta poprawi IR to wtedy nie dość, że czasy kompilacji powinny zdecydowanie spaść, ale również benchmarki powinny się poprawić. C, C++, Rust, Fortran, Delphi, Ada, etc. w teorii mają równy potencjał co do wydajności kodu maszynowego, jedyne różnice mogą wynikać z optymalizacji, a przy dobrze ogarniętych kompilatorach IMHO Rust i Ada powinny na tym zyskać najwięcej.

Co do prezentacji, którą pokazałeś, to co ona ma do rzeczy skoro ona w równym stopniu tak na prawdę odnosi się do wszystkich wymienionych wyżej języków? Jedyna różnica taka, że np. przy dostępie column/row-order zdecydowanie łatwiej popełnić taki błąd:

int arr[N][M];

// Napisać:

for (int j = 0; j < M; ++j)
  for (int i = 0; i < N; ++i)
     foo(arr[i][j]);

// Zamiast:

for (int i = 0; i < N; ++i)
  for (int j = 0; j < M; ++j)
     foo(arr[i][j]);

Niż:

let arr = [[isize; M]; N];

// Napisać:

for j in 0..M {
  for i in 0..N {
     foo(arr[i][j]);
  }
}

// Zamiast:

for row in &arr {
  for &elem in row {
    foo(elem);
  }
}

@hauleth: tak naprawdę to Fortran jest w nieumiejętnych rękach często szybszy od C (jeśli programista jest np. fizykiem kwantowym).
To że jakiś język ma potencjał na bycie szybszym od C - możliwe, ale to gdybanie.
Ja napisałem jak dzisiaj to widzę.
W zasadzie to mam nadzieję że powstaną koncepcje które zastąpią dzisiejsze nisko-poziomowe programowanie a w zamian będą się bardzo efektywnie kompilować do kodu maszynowego nie wymagając przy tym uwzględniania długości cache'a czy uzupełniania struktur jakimiś pseudo-elementami.
Takim językiem może być Julia: https://modelingguru.nasa.gov/docs/DOC-2625

• ale ona nie jest uniwersalna AFAIK.

@vpiotr nie nazwał bym fizyka kwantowego pracującego z Fortranem jako osobę o "nieumiejętnych rękach". Ten język jest de facto standardem w ich zastosowaniach, więc to zupełnie inna liga.

Nie jest to gdybanie, to jest realne spojrzenie na sprawę. Dla czego C wygrywa w Benchmarks Game:

• ludzie siedzieli i optymalizowali implementacje w C do granic niemożliwości, przykład nazwałbyś ten kod idiomatycznym kodem w C? Czy może raczej napisałbyś na szczycie // Here be dragons? Bo odpowiednik w Ruscie to całkiem idiomatyczne rozwiązanie (dodatkowo SIMD nie jest jeszcze stabilne, a Benchmarks Game działa na wersjach stabilnych języków.

powstaną koncepcje które zastąpią dzisiejsze nisko-poziomowe programowanie a w zamian będą się bardzo efektywnie kompilować do kodu maszynowego nie wymagając przy tym uwzględniania długości cache'a czy uzupełniania struktur jakimiś pseudo-elementami

To jest marzenie ściętej głowy, bo zakłada, że istnieje rozwiązanie, które sprawdzi się w każdym miejscu i czasie, a takiego nie ma. Więc albo masz większą kontrolę i zawsze możesz wybrać najlepsze rozwiązanie samemu, albo masz prostsze rozwiązania, ale nie zawsze optymalne.