Houston, mamy… buga! Największe błędy oprogramowania w misjach kosmicznych i wnioski na temat zapewniania jakości

Co może pójść nie tak? Kosmiczne bugi

Cykl życia oprogramowania w tradycyjnym ujęciu według ISTQB zazwyczaj składa się z następujących faz: tworzenia koncepcji, określania wymagań, projektowania, implementacji, testów, instalacji i zastępowania, wykorzystania produkcyjnego i utrzymania, czasami także wycofania. Już na wczesnych etapach może dojść do pomyłek, które w efekcie doprowadzą do katastrofy, nawet jeśli wszystkie późniejsze elementy układanki będą funkcjonować bez zarzutu. Takie błędy bywają bardzo kosztowne – zwłaszcza wtedy, gdy na szali jest ludzkie życie, ale także dosłownie, gdy organizacja traci setki milionów dolarów. Tego typu przypadki zdarzały się w dziejach misji kosmicznych i mimo że dla większości z nas ten temat nie jest zawodową codziennością, to śmiało możemy wyciągnąć ważne wnioski i pamiętać o konsekwencjach, które mogą płynąć z najbardziej błahych pomyłek również w naszych projektach.

Niniejszy przegląd misji kosmicznych, w których „coś” poszło nie tak, ukaże mnogość słabych punktów, które zaważyły na sukcesie misji lub miały znaczący wpływ na jej przebieg. Zazwyczaj można wyłonić kilka przyczyn, które doprowadziły do katastrofy lub po prostu do wystąpienia danego błędu, jednak możliwe jest wtedy także wskazanie źródła problemu, pierwszego punktu, który nie został zrealizowany tak jak powinien i od którego ostatecznie zależało niepowodzenie.

Błędy na wczesnym etapie powstawania oprogramowania

Mariner

Pierwsza misja programu Mariner, która wystartowała w lipcu 1962 roku i której celem był przelot w pobliżu Wenus, zakończyła się niepowodzeniem zaledwie 5 minut po starcie. Powodem tej porażki okazał się błąd, który wystąpił w specyfikacji oprogramowania. W jednym z równań zabrakło poziomej kreski (vinculum), oznaczającej zgrupowanie elementów wyrażenia, co pozwoliłoby na wyliczenie średniej ze zgromadzonych danych. Niestety napływające dane zostały potraktowane przez program jako nagłe zmiany wartości prędkości, które program starał się zniwelować gwałtownymi zmianami kursu rakiety. W rezultacie wydano polecenie samozniszczenia rakiety ze względu na anomalie w jej locie. Koszt tego błędu, którego prawdopodobnie można byłoby uniknąć dzięki dokładnej statycznej analizie na wczesnym etapie, wynosił 18,5 miliona dolarów (dzisiaj równowartość około 158 milionów dolarów).

Mars Polar Lander

Kolejnym przykładem misji, która zakończyła się niepowodzeniem mającym źródło już na etapie projektowania, była Mars Polar Lander z 1999 roku. Wskazuje się tutaj kilka aspektów, które przyczyniły się do porażki, ale jednym z nich było niewystarczająco starannie zaprojektowane oprogramowanie. W trakcie misji utracono łączność z lądownikiem, co było spowodowane tym, że logika oprogramowania akceptowała przejściowe sygnały jako prawidłowe informacje o lądowaniu, jeśli dwa kolejne odczyty na to wskazywały. W efekcie komputer wyłączył silniki rakietowe spowalniające już 40 metrów nad powierzchnią Marsa. Defekt ten nie został zidentyfikowany na wcześniejszym etapie, ponieważ zabrakło rzetelnego przeglądu specyfikacji oraz oprogramowanie odpowiadające za wykrycie kontaktu z podłożem nie zostało dostatecznie przetestowane w konfiguracji lotu.

Wnioski i rekomendacje:

• stosowanie formalnych i nieformalnych analiz i przeglądów
• wnikliwe testowanie na jak najwcześniejszym etapie – shift-left testing
• sprawdzenie oprogramowania na środowisku, które ma podobne zasoby i konfigurację co środowisko produkcyjne
• przeprowadzenie testów przeciążeniowych i symulowanie sytuacji awaryjnych techniką fault injection (wstrzykiwanie błędów)

Błędy związane z prawidłowością danych

Gemini 5

Błędy mogą również mieć źródło w nieprawidłowych danych wykorzystywanych w oprogramowaniu, które mogą wynikać na przykład z niewystarczającej dokładności lub użycia niewłaściwych jednostek. Ten pierwszy przypadek miał miejsce w 1965 roku podczas misji załogowej Gemini 5. Na szczęście nie spowodował katastrofy, ale efektem było wodowanie kapsuły z załogą w odległości 130 metrów od planowanego obszaru na Oceanie Atlantyckim. Przyczyną było wprowadzenie do programu prędkości kątowej Ziemi jako 360 stopni na dobę, chociaż prawidłowa dokładna wartość wynosiła 360,98 stopnia.

Mars Climate Orbiter

Jednym z najsłynniejszych błędów w historii misji pozaziemskich jest natomiast ten, który doprowadził w 1999 roku do awarii sondy Mars Climate Orbiter. Miała ona badać atmosferę Marsa, a także pomóc w komunikacji z utraconym wcześniej lądownikiem Mars Polar Lander. System nie wykrył i nie skorygował błędu w plikach wyjściowych programu „Sm_forces”, które zostały dostarczone zespołowi nawigacyjnemu w jednostkach angielskich (funt-siła sekunda – lbf-s) zamiast określonych jednostek metrycznych (niuton sekunda – Ns). Różnice tym spowodowane narastały stopniowo, więc początkowo nie wzbudziło to podejrzeń kontroli lotu. W rezultacie utracono sondę, która najprawdopodobniej uległa zniszczeniu w marsjańskiej atmosferze. Koszt misji oszacowano na ponad 300 milionów dolarów.

Wnioski i rekomendacje:

• analiza i weryfikacja danych wejściowych
• ujednolicenie jednostek lub stosowanie niezawodnych przeliczników
• dokładna i przejrzysta struktura danych
• przeglądy wymagań, projektów i planów akceptacji

Błąd z powodu… brakującego znaku

Phobos 1

Czasem nawet jedna literówka może zaważyć na losach ogromnego i kosztownego przedsięwzięcia, zwłaszcza jeśli wcześniej popełniono też inne błędy, których ryzyka nie oszacowano z należytą dokładnością. Przykładem tego jest radziecka sonda Phobos 1 z 1988 roku, programu kosmicznego mającego zbadać marsjański księżyc. Utracono z nią kontakt po tym, jak kontroler lotu ominął jeden znak w sekwencji komend wysłanych do statku kosmicznego. Spowodowało to niezamierzone uruchomienie programu testującego sterowanie, który wcześniej nie został usunięty z systemu. Program ten nie był już potrzebny, jednak dowództwo misji zdecydowało się na pozostawienie go i zabezpieczenie (nieskuteczne, jak się okazało), gdyż nie było czasu na jego poprawne usunięcie z pamięci tylko do odczytu (PROM).

Wnioski i rekomendacje:

• adekwatna analiza ryzyka
• zabezpieczenia przed przypadkowymi pomyłkami, aby nie były w stanie doprowadzić do katastrofy
• oczyszczenie gotowego produktu z niepotrzebnych funkcji

Błąd nadpisania pamięci

Viking 1

Nawet gdy statek kosmiczny bezpiecznie wystartuje, dotrze do celu, wykona zaplanowane eksperymenty i przekaże informacje na Ziemię, nadal istnieje ryzyko, że coś pójdzie nie tak. Taki los spotkał misję Viking 1 w 1982 roku. Lądownik wykonywał badania na Marsie przez 6 lat, do momentu, gdy z powodu błędu utracono z nim kontakt, którego nigdy już nie udało się odzyskać. Doszło do tego, gdy pogarszająca się wydolność baterii w lądowniku skłoniła inżynierów na Ziemi do przesłania komend mających poprawić działanie oprogramowania odpowiedzialnego za ładowanie. Niestety podczas tej operacji parametry anteny wskazującej w pamięci komputera lądownika zostały przypadkowo nadpisane parametrami ładowania akumulatora.

Mars global Surveyor

Podobna sytuacja miała miejsce podczas misji Mars Global Surveyor, której głównym zadaniem była obserwacja pogody oraz stworzenie map topograficznych. Dzięki danym z tej misji, dowiedziono, że na Marsie występuje woda. Po 7 latach wykonywania badań, w czerwcu 2006 roku, nastąpiła awaria sondy, która polegała na tym, że aktualizacja związana z parametrami kierunku wskazywania anteny używanej w operacjach awaryjnych została zapisana do nieprawidłowego adresu pamięci. Następnie w listopadzie polecenie wysłane do Mars Global Surveyor spowodowało, że panele słoneczne zmieniły swoje położenie, lecz na Ziemię

Wnioski i rekomendacje:

• dokładne przeglądy wszystkich nierutynowych zmian przed ich produkcyjnym wdrożeniem
• adekwatna ocena trybów awaryjnych
• zadbanie o należytą dokumentację i przeszkolenie zespołu odpowiadającego za testy, ponieważ długotrwałe projekty niosą ryzyko związane ze zmianą personelu i ewentualną utratą informacji bądź zmianą procedur

Błąd w integracji oprogramowania i sprzętu  

CryoSat-1 i Zenit-3SL

W tak złożonych systemach, jakimi są statki kosmiczne, również integracja oprogramowania ze sprzętem jest podatna na błędy. W momencie, gdy to oprogramowanie steruje sprzętem, może dojść do awarii software’u lub braku reakcji hardware’u na docierające do niego instrukcje. Tak było w przypadku dwóch misji mających wynieść na orbitę satelity Zenit-3SL (2000 r.) i CryoSat-1 (2005 r.). Pierwsza z nich zakończyła się niepowodzeniem z powodu programu wykorzystywanego na Ziemi, który nie zamknął zaworu w systemie pneumatycznym drugiego stopnia rakiety, odpowiedzialnego za ruchy silnikiem sterującym. Około 8 minut po starcie, gdy drugi stopień rakiety zbliżał się do końca swego działania, zdecydowano o przerwaniu misji, a zarówno ładunek satelitarny, jak i wynosząca go na orbitę rakieta spadły do Oceanu Spokojnego. W przypadku CryoSat-1 zawinił natomiast błąd oprogramowania kontroli lotu, które nie wysłało polecenia wyłączenia silników drugiego stopnia.

SpaceX

Również SpaceX mierzył się z problemem braku potrzebnej integracji oprogramowania ze sprzętem, kiedy 28 czerwca 2015 roku bezzałogowa rakieta Falcon 9 podczas misji SpaceX CRS-7 eksplodowała niemal 2 minuty po starcie.

Niestety nie udało się wówczas odzyskać ładunku kapsuły Dragon o wartości około 120 milionów dolarów, który miał być dostarczony na ISS. Elon Musk w wypowiedziach wskazał, że kapsułę można byłoby odzyskać, gdyby oprogramowanie wydało polecenia otwarcia spadochronu podczas incydentu:

“That is probably the saddest thing about this, is that, with just a bit of different software, Dragon would have made it” („To chyba najsmutniejsze w tym wszystkim, że gdyby oprogramowanie było inne, Dragon by ocalał”).

Wnioski i rekomendacje:

• oprogramowanie jest odpowiedzialne za działanie sprzętu – kluczowe znaczenie integracji
• zwiększenie roli testów scenariuszy awaryjnych i specjalnych procedur
• analiza ryzyka uwzględniająca negatywne przypadki
• wdrożenie wszelkich możliwych środków, które pomogą odzyskać sprzęt w przypadku awarii

Błąd przeciążenia pamięci

Spirit

Oprogramowanie łazika Spirit zawierało błąd, który ujawnił się 21 stycznia 2004 roku, czyli dopiero w 18. marsjańskiej dobie (sol). Pojawiły się wówczas problemy z komunikacją z łazikiem, który nie wysyłał żadnych danych i zaobserwowano, że w ciągu trzech dni restartował się 60 razy. Okazało się, że w miarę gromadzenia informacji ilość zajętej pamięci wzrastała coraz bardziej. 18. sola blok pamięci był pełny, a proces ponownego uruchamiania został zatrzymany z powodu niemożności odczytania plików systemowych. Inżynierowie rozważali wcześniej potencjalne problemy wywołane długotrwałą pracą łazika, ale przeprowadzili test, symulując tylko 10 soli. Na szczęście udało się sformatować pamięć i zaktualizować oprogramowanie tak, aby łazik mógł z powodzeniem kontynuować pracę.

Wnioski i rekomendacje:

• kwestie postrzegane jako niski priorytet mogą okazać się kluczowe dla sukcesu misji
• przeprowadzanie kompletnych testów obciążeniowych i przeciążeniowych
• testy w warunkach możliwie jak najbardziej zbliżonych do środowiska produkcyjnego

Problemy z synchronizacją

Mars Pathfinder

Istnieje wiele czynników, które wpływają na powodzenie misji kosmicznych oraz osiąganie zaplanowanych celów, zaś jednym z niezwykle istotnych jest czas.

W trakcie misji Mars Pathfinder w 1997 roku komputer lądownika nieoczekiwanie zresetował się czterokrotnie w ciągu kilku dni. Jak ustalono, było to spowodowane otwartym zadaniem oprogramowania, które nie zamykało się w wyznaczonym czasie. Problem udało się odtworzyć w NASA Jet Propulsion Laboratory. Przygotowaną łatkę przesłano transmisją radiową.

Starliner

W grudniu 2019 roku odbył się lot statku kosmicznego Starliner Boeinga. Jego celem było przetestowanie komercyjnego statku załogowego, od startu, przez spotkanie i dokowanie ze stacją kosmiczną, po ponowne wejście w ziemską atmosferę i wodowanie. W trakcie lotu odkryto dwa problemy związane z oprogramowaniem – jeden z nich dotyczył synchronizacji (przesunięcie zegara o 11 godzin w stosunku do czasu rzeczywistego), a drugi modułu serwisowego. W wydanym oświadczeniu stwierdzono, że defekty oprogramowania, szczególnie w złożonym kodzie statku kosmicznego, nie były zaskoczeniem, jednak było wiele przypadków, w których procesy zapewniania jakości oprogramowania Boeinga nie wykryły błędów.

Ingenuity

W 2021 roku na powierzchni Marsa wylądował łazik Perseverance, od którego odłączony został niewielkich rozmiarów śmigłowiec-dron Ingenuity. Podczas jego testowego lotu zauważono, że komputer lotu nie zdołał prawidłowo przejść ze stanu „pre-flight” do „flight”. Problem polegał na tym, że gdy tryby te miały się zmienić, następowało sprawdzenie, czy komputer pokładowy helikoptera jest sprawny. Na tym etapie pojawiał się problem z synchronizacją zadań. Zespół opracował modyfikację oprogramowania sekwencji poleceń, która obejmowała ponowną instalację oprogramowania do sterowania lotem Ingenuity. Aktualizacja zmodyfikowała proces uruchamiania dwóch kontrolerów lotu i umożliwiła bezpieczne przejście sprzętu i oprogramowania do stanu lotu.

Wnioski i rekomendacje:

• nadawanie zadaniom odpowiednich priorytetów
• przeprowadzanie rzetelnych testów i symulacja warunków środowiska produkcyjnego
• posiadanie środowiska testowego, na którym można dokładnie odtworzyć błędy

Kiedy reużywalność nie jest zaletą

Katastrofa Ariane 5

4 czerwca 1996 roku wystartowała rakieta Ariane 5 z ładunkiem satelitów Europejskiej Agencji Kosmicznej – Cluster. Niestety eksplodowała już po 37 sekundach, powodując straty szacowane na 370 milionów dolarów. Jako główną przyczynę tego wydarzenia najczęściej w raportach wskazuje się fakt, że oprogramowanie wykorzystywało kod napisany pod kątem misji Ariane 4, który nie był dostosowany do warunków Ariane 5 (m.in. w kontekście trajektorii lotu).

W tej katastrofie można wskazać kilka perspektyw. Błąd w oprogramowaniu był nieprawidłowo obsłużonym wyjątkiem wynikającym z konwersji 64-bitowej liczby zmiennoprzecinkowej na 16-bitową liczbę całkowitą ze znakiem. Wartość przekonwertowanej liczby była większa niż ta, która mogła być reprezentowana przez 16-bitową liczbę całkowitą, co skutkowało nieprzewidzianym błędem w kodzie Ada.

Przewodnik po świecie testów funkcjonalnych.

Sprawdź, kto przeprowadza unit testy, testy integracyjne, testy systemu oraz testy akceptacyjne.

Przeczytaj artykuł

Jednak już na etapie projektowania specyfikacji systemu nie zapewniono mechanizmu obsługi wyjątków niezwiązanych ze sprzętem, dlatego przypadkowy błąd oprogramowania nie został obsłużony. W efekcie poprawnie działający procesor w systemie nawigacyjnym został wyłączony, a wkrótce potem procesor zapasowy „zawiódł” w ten sam sposób. Gdyby projekt oprogramowania został wykonany staranniej, udałoby się uniknąć sytuacji, w których wyjątki oprogramowania wstrzymują poprawnie działający hardware, a tym samym – zapobiec awarii. Wskazuje się także, że katastrofa była wynikiem nieprawidłowej analizy zmieniających się wymagań, które dla Ariane 5 różniły się od wcześniejszych modeli rakiety. Fragment kodu, który spowodował katastrofę, właściwie nie był potrzebny już po starcie, a jednak funkcjonował. Wini się także niedopracowane procedury testowe. Na przykład, jak stwierdzono w raporcie, nie przeprowadzono żadnych naziemnych testów akceptacyjnych lub przeglądu, które pozwoliłyby sprawdzić, czy system nawigacyjny będzie zachowywać się prawidłowo, gdy zostanie poddany sekwencji odliczania i czasu lotu oraz trajektorii Ariane 5.

Milstar

W 1999 roku rakieta Titan IV miała wynieść na orbitę satelitę Milstar. Niestety błąd oprogramowania przyczynił się do niepowodzenia tej misji. Stwierdzono, że był to wynik nieprawidłowo zaprogramowanego równania w komputerze naprowadzania. Przyczyniło się do tego błędne założenie Biura Programu Titan, które zdecydowało o użyciu wykorzystywanego w przeszłości oprogramowania, które jak dotąd było stabilne i niezawodne. Zakładano, że ryzyko maleje wraz z upływem czasu, ponieważ kumuluje się bezwypadkowa eksploatacja. W rzeczywistości ryzyko zwykle wzrasta z czasem, szczególnie w systemach intensywnie korzystających z oprogramowania i w środowiskach, w których zmieniają się warunki.

Wypadki Ariane 5 i Titan IV (Milstar) były związane z wykorzystywaniem kodu, który nie był potrzebny (znajdował się w ponownie używanym oprogramowaniu zaprojektowanym dla innych statków kosmicznych). Jednakże, ponownie używane oprogramowanie jest prawdopodobnie mniej bezpieczne, ponieważ pierwotne decyzje dotyczące wymaganego zachowania oprogramowania zostały podjęte dla innego projektu systemu i opierały się na innych założeniach środowiskowych.

Wnioski i rekomendacje:

• reużywalność pozwala oszczędzić koszty, ale tylko jeśli stosowane już wcześniej komponenty podlegają równie rygorystycznej weryfikacji jak nowe
• testowanie powinno się odbywać w warunkach jak najbardziej zbliżonych do rzeczywistych, z realistycznymi danymi, sprzętem i symulując kompletne procesy
• szczegółowe przeglądy oprogramowania dla każdego elementu, który je zawiera
• weryfikacja zakresów wartości przyjmowanych w oprogramowaniu
• przegląd rozwiązań potencjalnych problemów w oprogramowaniu komputera pokładowego
• wyeliminowanie niepotrzebnego kodu lub funkcji bądź oddzielenie od kodu o znaczeniu krytycznym

Z kolejnej części artykułu pt. Złote zasady wytwarzania oprogramowania w przemyśle kosmicznym będziecie mogli dowiedzieć się, jakie są dobre praktyki wytwarzania oprogramowania w tej branży i jak zwiększają szanse powodzenia tych nieraz niebotycznie kosztownych projektów.