Czym zajmował się Pana zespół w trakcie przygotowań do misji sondy Curiosity?

Tworzyliśmy oprogramowania sterujące sondą zarówno podczas lotu i lądowania, jak i w trakcie misji na Marsie. Kieruje ono wszystkimi urządzeniami sondy - silnikami, które nią poruszają, i poszczególnymi jej elementami, radarami, systemami multimedialnymi i tymi odpowiedzialnymi za komunikację z Ziemią. Pierwotnie sonda Curiosity miała wylecieć dwa lata wcześniej. Ale wielu elementów nie udało się przygotować na czas, w tym oprogramowania. W 2009 r. powierzono mi stanowisko Project Delivery Manager i zadanie dokończenia budowy systemów sondy. Zaczęliśmy praktycznie od nowa: przepisaliśmy oprogramowanie, stworzyliśmy nowe procedury. Od nowa opisane zostały też wymagania systemowe.

Jak powstaje oprogramowanie dla sondy, która ma wylądować na innej planecie?

Podobnie jak w tworzeniu każdego dedykowanego oprogramowania, jest kilka faz takiego projektu. Określamy najważniejsze wymagania i etapy. Decydujemy o architekturze, platformie i możliwościach systemu. W miarę prac wchodzimy w detale. System zarządzający Curiosity został podzielony aż na 154 moduły! Każdy tworzył inny zespół, który przygotowane wcześniej wymagania przekładał na konkretne elementy systemu - strukturę danych, procedury. To najbardziej złożony projekt zrealizowany w Jet Propulsion Laboratory. Systemy sterujące pracą sond stają się bowiem coraz bardziej skomplikowane. Dotyczy to np. rozwiązań do przechowywania plików. Wcześniej pracowałem przy tworzeniu oprogramowania dla sondy Cassini, miała ona tylko ok. 30 modułów. Każdy kontrolował inny element. Odpowiadałem za system sterowania, decydujący o tym, w którym kierunku Cassini się porusza, gdzie patrzy, co fotografuje.

Po napisaniu każdego z modułów systemu Curiosity w kolejnym etapie sprawdzaliśmy to, co powstało. Osoby tworzące jeden z elementów oprogramowania sprawdzały pracę innych kolegów i odwrotnie. Do testów wykorzystaliśmy także oprogramowanie klasy SCA (Static Code Analysis), znacznie bardziej zaawansowane od kompilatorów kodu. Po tym etapie łączyliśmy wszystkie moduły w gotowe systemy. Kolejny test był przeprowadzony na docelowym urządzeniu albo w środowisku wirtualnym. W ostatnim etapie zainstalowaliśmy oprogramowanie na poszczególnych elementach sondy Curiosity, a później złożyliśmy całą sondę i przetestowaliśmy różne scenariusze, które mogą ją spotkać w trakcie misji.

Dlaczego po wylądowaniu przez 20 godzin wgrywano nowe oprogramowanie dla Curiosity? Jak często będzie aktualizowane oprogramowanie sondy w czasie jej ponad dwuletniej misji?

W czasie lotu po prostu pojawiła się kolejna wersja oprogramowania. Ono właściwie nieustannie się zmienia. Poprzednia wersja została załadowana siedem miesięcy przed lądowaniem Curiosity. Dodatkowo niektóre elementy - niepotrzebne w czasie lotu i lądowania - nie były jeszcze skończone, przetestowane, czy wręcz napisane. Dotyczyło to głównie modułów niezbędnych do prowadzenia misji już na powierzchni Marsa. Kolejne testy spowodowały, że w już gotowych elementach oprogramowania Curiosity pojawiło się wiele poprawek. W czasie misji sondy ogranicza nas też pojemność pamięci. W ramach uaktualnienia oprogramowania wykasowaliśmy zbędne już elementy, a załadowaliśmy dodatkowe moduły odpowiedzialne za nawigację po Czerwonej Planecie czy unikanie przeszkód, na które może napotkać Curiosity. Wymagają one sporo miejsca. Do tego celu można wykorzystać zwolnioną pamięć.

Kiedy więc Curiosity ruszy z miejsca?

Około dwóch tygodni po ładowaniu. Na początek na krótkim dystansie, aby skalibrować moduł odpowiedzialny za ruch.

Jak dużo osób pracujących nad oprogramowaniem dla Curiosity wciąż zaangażowanych jest w projekt?

Około 10 osób zajmuje się rozwojem i zarządzaniem tym projektem. Wynajdują one m.in. w trakcie testów kolejne błędy. Ale jednocześnie budują następną wersję oprogramowania dla Curiosity. Załadujemy go do sondy za jakieś 2-3 miesiące.

Na ile "inteligentna" powinna być sonda kosmiczna, zważywszy na opóźnienia w transmisji między Ziemią i Marsem rzędu 14 minut?

Opóźnienie to nie jedyny problem. Przez wiele godzin każdego dnia sonda jest dla nas niewidoczna. Znajduje się na drugiej stronie Marsa. Nie wykorzystaliśmy rozwiązań typu Artificial Intelligence, ale są inne sposoby zautomatyzowania pracy sondy. My zastosowaliśmy trzy.

Pierwszy to system fault protection - który ma zapobiegać problemom związanym z uszkodzeniami mechanicznymi. Wiele elementów sondy Curiosity odpowiada za badanie jej samej, sprawdzanie, czy wszystko działa poprawnie. Jeśli coś jest nie tak, system sam decyduje, jaki jest prawdopodobny problem i jak go rozwiązać. Może wymienić jedną z części albo wyłączyć uszkodzony moduł do czasu połączenia z Ziemią. Wiele elementów jest zdublowanych, chociażby sam komputer. Po raz pierwszy w sondzie zainstalowano dwie jednostki centralne. Ta "inteligencja" zapisana jest częściowo w oprogramowaniu typu firmware poszczególnych urządzeń, a częściowo w systemie, który stworzyliśmy.

Drugi sposób to zapisanie w systemie listy komend do wykonania w pewnej sekwencji. Jest to tzw. sequence engine. Mechanizm jest na tyle zaawansowany, że kontroluje wykonanie wcześniejszych komend przed uruchomieniem kolejnej. Procedura stosowana jest głównie podczas lądowania.

Dodatkowo w samym systemie Curiosity zawarliśmy dużo logiki. Każdy program jest tak skonstruowany, że w zależności od "stanu" - tzw. state machine - w którym się znajduje, wykonuje konkretne zadania. Każdy z systemów dostosowuje swoje działanie do otoczenia i celu. Jak się to złoży w całość, to wygląda nieco jak inteligencja.

Czy zabezpieczyli się Państwo przed sytuacją, która spotkała sondę Viking 1? Chodzi o wysłanie błędnej komendy, która spowodowała utratę kontaktu z nią w roku 1982? Na ile od tego czasu zmieniła się technologia stosowana przez NASA?

Błędne komendy to największe ryzyko dla misji sond kosmicznych. Wiele z nich z tego właśnie powodu się nie powiodło. Staraliśmy się wyciągnąć wnioski i zabezpieczyliśmy na kilka różnych sposobów przed taką ewentualnością. Gdy listy komend są układane na Ziemi, sprawdza się je w tzw. flight rules database. Przechowuje ona wiedzę na temat tego, czego można dokonać. Znajdują się tam też informacje o tym, że jakiejś komendy nie można wykonać w określonej sytuacji lub że jej wartość nie może przekroczyć ustalonych parametrów minimalnych i maksymalnych. Dodatkowo sama sonda sprawdza, czy może daną komendę wykonać. Podczas procesu lądowania Curiosity ograniczyliśmy liczbę komend do minimum, aby nie przeszkadzały podczas tej procedury. Ostatnie zabezpieczenie to trzymanie się ściśle określonej sekwencji komend, np. odpalenie głównych silników musi poprzedzać seria innych zdarzeń. Raz odpalonych silników nie da się uruchomić ponownie. Zużywają całe dostępne na ten cel paliwo.

Po pierwsze jest to Embeded Real-Time Operating System. Jest to nie tylko system wbudowany, stosowany w wielu urządzeniach codziennego użytku, ale dodatkowo gwarantuje, że każda z operacji zakończy się w założonym czasie. Korzystając z komputerów, wiemy, że często otwierając jakąś aplikację, czekamy kilka sekund lub nawet minut, aby coś się zadziało, nie wiedząc, czy program w ogóle się "uruchamia". Podczas misji sond nie można sobie na to pozwolić. W trakcie lądowania kilka sekund opóźnienia może zakończyć się katastrofą i rozbiciem sondy o powierzchnię planety. Tego typu systemy pozwalają również na znacznie lepszą kontrolę nad współpracą oprogramowania ze sprzętem, w który zostało wbudowane. Na przykład umożliwiają całkowicie wyłączenie niektórych elementów.

Na jakich platformach działa oprogramowanie? Kiedyś mówiło się, że NASA jest konserwatywne i jeszcze do niedawna korzystało z układów Intela x86. Teraz to - jak słyszałem - także niezbyt szybki procesor Power PC 133 MHz…

To prawda. Znacznie ogranicza nas dostępność platform, na które możemy tworzyć oprogramowanie. Jednak to nie tyle konserwatyzm NASA, ile fakt, że rynek kosmiczny jest bardzo mały. To powoduje, że nie inwestuje się zbyt wielkich kwot w innowacje. Jednocześnie stosowane rozwiązania muszą spełnić wiele dodatkowych wymogów, w tym np. być odporne na promieniowanie. Powstające zaś nowe rozwiązania długo czekają na akceptację NASA, które nie chce ryzykować misji wartych miliardy dolarów. To powoduje, że ograniczony jest dostęp do odpowiednich technologii. Stosowane przez NASA komputery nie mają nawet pamięci typu L2Cache. Z roku na rok rynek kosmiczny coraz bardziej odstaje od technologii rozwijanej na Ziemi.

Jak trafił Pan do Jet Propulsion Laboratory?

Na California State University studiowałem matematykę i informatykę. Jeszcze przed zakończeniem szkoły ściągnięto mnie do pracy w NASA. Poszukiwano administratora jednego z systemów. Do pracy przychodziłem wówczas zaledwie na kilka godzin w tygodniu. Zarządzany przeze mnie komputer był większy niż samochód typu van, a miał moc obliczeniową zaledwie 1 MIPSA. Po studiach otrzymałem propozycję stałej pracy. Później zacząłem programować. Curiosity to czwarty projekt, w którym biorę udział, choć dopiero drugi - po Cassini - dotyczący misji kosmicznej.

Dużo Polaków pracuje w NASA?

Jest ich bardzo wielu. W Jet Propulsion Laboratory osobiście znam pięciu. A znacznie więcej jest osób z polskimi nazwiskami. Nie mogę jednak znać wszystkich, bo w samym JPL pracuje 5 tys. osób, a to tylko jeden z kilkunastu ośrodków NASA.

Nad jakim nowym projektem będzie Pan teraz pracował?

Mam stworzyć architekturę nowej generacji systemów na potrzeby nowych projektów. Zastanawiamy się, jak powinny działać, także w kontekście kolejnych misji na Marsa. Co prawda jeszcze nie tych załogowych, ale już myśli się o misji, która przywiozłaby pozyskane próbki na Ziemię.