Z analizy nieudanych misji kosmicznych można wyciągnąć kilka istotnych wniosków. Pierwszym z nich jest wymóg przeprowadzania analiz i przeglądów na wczesnym etapie procesu tworzenia oprogramowania, aby zidentyfikować błędy i zapobiec poważnym konsekwencjom w przyszłości. Aby uniknąć błędów w poprawności danych i uchronić produkt przed niezamierzonymi błędami, które mogłyby być katastrofalne, należy jak najwcześniej wdrożyć proces testowania.
Już na wczesnych etapach tworzenia oprogramowania może dojść do pomyłek, które niewychwycone na czas, doprowadzą do katastrofy. Nawet jeśli późniejsze elementy tworzonej przez programistę układanki funkcjonują bez zarzutu. Takie błędy bywają bardzo kosztowne - zwłaszcza gdy na szali jest ludzkie życie, lecz także gdy oznaczają utratę setek milionów dolarów.
Misje kosmiczne, które zakończyły się niepowodzeniem z powodu niewystarczającej kontroli nad oprogramowaniem
1. Błędy na wczesnym etapie powstawania oprogramowania
Mariner
W przypadku misji Mariner z 1962 roku kluczowy okazał się błąd, który wystąpił w specyfikacji oprogramowania. Brak jednej poziomej linii vinculum, można wycenić na kwotę stanowiącą równowartość dzisiejszych około 158 milionów dolarów. Błędu tego prawdopodobnie można by uniknąć, dzięki dokładnej statycznej analizie na wczesnym etapie.
2. Błędy związane z prawidłowością danych
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, co początkowo nie wzbudzało podejrzeń kontroli lotu. Ostatecznie jednak utracono sondę, która najprawdopodobniej uległa zniszczeniu w marsjańskiej atmosferze. Koszt misji oszacowano na ponad 300 milionów dolarów.
3. Błąd z powodu… brakującego znaku
Phobos 1
Czasem jedna literówka może zaważyć na losach ogromnego i kosztownego przedsięwzięcia, zwłaszcza jeśli wcześniej popełniono 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, będąca częścią programu kosmicznego mającego zbadać marsjański księżyc. Utracono z nią kontakt po tym, gdy 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).
4. Błąd nadpisania pamięci
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. Jej istotą było to, że aktualizacja związana z parametrami kierunku wskazywania anteny używanej w operacjach awaryjnych, została zapisana do nieprawidłowego adresu pamięci. Polecenie wysłane do Mars Global Surveyor spowodowało, że panele słoneczne zmieniły swoje położenie, lecz na Ziemię docierały sygnały o zablokowaniu się jednego z nich. Statek kosmiczny został umieszczony w nietypowej orientacji awaryjnej a niekorzystne warunki spowodowały dalsze problemy. Zakłada się, że przegrzanie się baterii i utrata zasilania spowodowały całkowitą stratę statku kosmicznego.
5. Błąd w integracji oprogramowania i sprzętu
SpaceX
Również SpaceX mierzył się z problemem braku potrzebnej integracji oprogramowania ze sprzętem. 28 czerwca 2015 roku bezzałogowa rakieta Falcon 9, realizująca misję SpaceX CRS-7 eksplodowała około 2 minut 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.
Jak wskazywał Elon Musk w wypowiedziach kapsułę można byłoby odzyskać, gdyby oprogramowanie wydało polecenia otwarcia spadochronu podczas incydentu. “To chyba najsmutniejsze w tym wszystkim, że gdyby oprogramowanie było inne, Dragon by ocalał” komentował założyciel SpaceX.
6. Błąd przeciążenia pamięci
Spirit
Oprogramowanie łazika Spirit zawierało błąd, który ujawnił się 21 stycznia 2004 roku, czyli w 18. marsjańskiej dobie (sol) trwania misji. Pojawiły się wówczas problemy z komunikacją z łazikiem, który nie wysyłał żadnych danych oraz restartował się 60 razy w ciągu trzech dni. 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, jednak przeprowadzili symulacje obejmującą czas 10 soli. Ostatecznie udało się sformatować pamięć i zaktualizować oprogramowanie tak, aby łazik mógł z powodzeniem kontynuować pracę.
7. 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, a przygotowaną łatkę przesłano transmisją radiową.
8. 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). 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.
"Dokładna analiza i weryfikacja danych wejściowych, standaryzacja jednostek oraz stosowanie godnych zaufania współczynników konwersji to kolejne wnioski. Oprócz przeglądu wymagań, projektów i planów akceptacji, ważne jest, aby pamiętać, że dane powinny być skonstruowane dokładnie i przejrzyście. Aby zapobiec niezamierzonym błędom, które mogą mieć negatywny wpływ na całą misję, należy przeprowadzać analizy ryzyka. Analiza ryzyka, włączenie procesu testowania do wczesnych faz powstawania software’u, testowanie produktu w środowiskach o różnych konfiguracjach i zasobach, automatyzacja procesu wytwarzania i integracji oprogramowania (CI/CD) czy pokrywanie funkcjonalności różnymi przypadkami testowymi to uniwersalne zasady, które powinny znaleźć zastosowanie w projektach z innych branż" - ocenia ekspertka Inetum.
"Obserwacje wyniesione z doświadczeń sektora Aerospace, chociaż ich kontekst może wydawać się odległy od codzienności projektowej specjalisty w zakresie testów, w rzeczywistości są niezwykle cenne" - podsumowuje Agnieszka Skokowska, Principal QA Leader w Inetum Polska.
Źródło: Inetum
