Jakie jest wbudowane oprogramowanie Mars Curiosity Rover?

Mars Curiosity Rover wylądował pomyślnie, a jeden z filmów promocyjnych „7 minut terroru” przechwala się tam będąc 500.000 linii kodu. To bez wątpienia skomplikowany problem. Ale to dużo kodu, na pewno było za tym sporo wysiłku programistycznego. Czy ktoś wie coś o tym projekcie? Mogę sobie tylko wyobrazić, że jest to jakiś osadzony C.

Obsługuje 2,5 miliona linii C na procesorze RAD750 produkowanym przez BAE . JPL ma nieco więcej informacji, ale ja podejrzewam, wiele szczegółów nie są nagłaśniane. Wygląda na to, że skrypty testowe zostały napisane w języku Python.

Podstawowym systemem operacyjnym jest VxWorks RTOS firmy Wind River . RTOS w pytaniu można programować w C, C ++ lub Java, Ada. Jednak tylko C i C ++ są standardem w systemie operacyjnym, Ada i Java są obsługiwane przez rozszerzenia. Wind River dostarcza ogromną ilość szczegółów, jak i jak VxWorks .

Podstawowy mikroukład jest prawie absurdalnie solidny . Jego specyfikacja może początkowo wydawać się niewielka, ale co 15 lat może mieć tylko jeden „niebieski ekran”. Pamiętaj, że jest to bombardowane przez promieniowanie, które zabiłoby człowieka wiele razy. W kosmosie wytrzymałość wygrywa z prędkością. Oczywiście taka wytrzymałość wiąże się z pewnymi kosztami. W tym przypadku jest to od 200 000 do 500 000 USD.

Programista Erlang mówi o funkcjach komputerów i bazy kodów w Curiosity.

Kod oparty jest na kodzie MER ( Spirit and Opportunity ), które zostały oparte na ich pierwszym lądowniku, MPF ( Sojourner ). To 3,5 miliona linii C (w większości generowanych automatycznie), działających na procesorze RA50 wyprodukowanym przez BAE i system operacyjny VxWorks . Ponad milion linii zostało ręcznie zakodowanych.

Kod jest zaimplementowany jako 150 oddzielnych modułów, z których każdy pełni inną funkcję. Silnie sprzężone moduły są zorganizowane w komponenty, które wyodrębniają zawarte w nich moduły i „określają konkretną funkcję, działanie lub zachowanie”. Te komponenty są dalej zorganizowane w warstwy, a „nie ma więcej niż 10 komponentów najwyższego poziomu”.

Źródło: Keynote talk by Benjamin Cichy podczas warsztatów 2010 na temat oprogramowania lotów kosmicznych (FSW-10) , slajdy, audio i wideo (zaczyna się od przeglądu misji, dyskusji na temat architektury na slajdzie 80).

Ktoś w Hacker News zapytał „Nie jestem pewien, co oznacza, że ​​większość kodu C jest generowana automatycznie. Z czego?”

Nie jestem w 100% pewien, chociaż prawdopodobnie w tym roku lub innym roku jest osobna prezentacja opisująca proces ich automatycznego generowania. Wiem, że był to ogólnie popularny temat na konferencji FSW-11.

Simulink to możliwość. Jest to komponent MATLAB popularny wśród inżynierów mechaników, a zatem większości inżynierów do nawigacji i sterowania, i pozwala im „kodować” i symulować rzeczy bez myślenia, że ​​kodują.

Programowanie oparte na modelach jest zdecydowanie rzeczą, o której przemysł powoli zaczyna zdawać sobie sprawę, ale nie wiem, jak dobrze radzi sobie w JPL lub czy zdecydowaliby się go użyć na początku projektu.

Trzecią i najbardziej prawdopodobną możliwością jest kod komunikacyjny. We wszystkich systemach kosmicznych musisz wysyłać polecenia do oprogramowania lotu z oprogramowania naziemnego, odbierać dane telemetryczne z oprogramowania lotu i przetwarzać je za pomocą oprogramowania naziemnego. Każdy pakiet komend / telemetrii jest heterogeniczną strukturą danych i konieczne jest, aby obie strony pracowały na podstawie dokładnie tej samej definicji pakietu i sformatowały pakiet, aby był poprawnie sformatowany z jednej strony i przeanalizowany z drugiej. Wymaga to uporządkowania wielu rzeczy, w tym typu danych, rozmiaru i endianizmu (chociaż ta ostatnia jest zwykle kwestią globalną; możesz mieć na pokładzie wiele procesorów o różnej endianizacji).

Ale to tylko powierzchowność. Potrzebujesz wielu powtarzających się kodów po obu stronach, aby obsłużyć takie rzeczy, jak rejestrowanie, sprawdzanie poprawności poleceń / telemetrii, sprawdzanie limitu i obsługa błędów. A potem możesz robić bardziej wyrafinowane rzeczy. Załóżmy, że masz polecenie ustawienia wartości rejestru sprzętowego, a ta wartość jest wysyłana z powrotem w telemetrii w określonym pakiecie. Można wygenerować oprogramowanie naziemne, które monitoruje ten punkt telemetrii, aby upewnić się, że po ustawieniu tej wartości rejestru telemetria zmieni się w celu odzwierciedlenia zmiany. I oczywiście niektóre punkty telemetryczne są ważniejsze niż inne (np. Główny prąd magistrali) i są przeznaczone do zejścia w wielu pakietach, co wymaga dodatkowego kopiowania po stronie lotu i duplikacji danych po stronie naziemnej.

Mając to wszystko o wiele łatwiej (moim zdaniem) napisać jedną kolekcję statycznych plików tekstowych (w formacie XML, CSV lub niektórych DSL / what-have-you), uruchomić je za pomocą skryptu Perl / Python i presto! Kod!

Nie pracuję w JPL, więc nie mogę podać żadnych szczegółów, których nie ma w filmie, z jednym wyjątkiem. Słyszałem, że automatycznie generowany kod C jest napisany przez skrypty Pythona, a ilość automatycznego kodowania w projekcie różni się znacznie w zależności od tego, kto prowadzi FSW.