Houston, mamy buga – dlaczego małe błędy w oprogramowaniu mogą słono kosztować? Przykład branży kosmicznej

Newsroom BrandsIT
Newsroom BrandsIT - NewsRoom Brandsit
12 min

Zapewnianie optymalnego jakościowego oprogramowania jest kluczowe dla każdej organizacji, która z niego korzysta. Jak pokazuje praktyka, prędzej czy później mogą pojawić się błędy w jego działaniu, a ich katastrofalne skutki są szczególnie widoczne na przykład w przypadku misji kosmicznych.

Właśnie w sektorze kosmicznym czy Aerospace szczególnego znaczenia nabiera Quality Assurance. Znaczenie zagadnienia sprawdzania poprawności kodu rośnie zwłaszcza w dobie rozwoju narzędzi automatyzujących pracę wykonywaną dotychczas przez programistów.

Eksperci Inetum Polska wskazują dobre praktyki związane z QA, w kontekście błędów popełnionych przy okazji zakończonych niepowodzeniem misji kosmicznych. Wyciągnięte z nich wnioski wdrażają m.in. w projektach realizowanych dla sektora lotniczego, w którym rozwiązania IT odgrywają olbrzymią rolę.

Ziemskie bugi o kosmicznym znaczeniu

W lipcu 1962 roku wystartowała pierwsza misja programu Mariner, której celem był przelot w pobliżu Wenus. Zakończyła się ona niepowodzeniem po zaledwie 5 minutach od startu. Powodem okazał się błąd w specyfikacji oprogramowania. W jednym z równań zabrakło poziomej kreski (vinculum), oznaczającej zgrupowanie elementów wyrażenia. Wspomniane vinculum pozwoliłby na wyliczenie średniej ze zgromadzonych danych. Jego brak powodował, że napływające dane były potraktowane jako zmiany wartości prędkości, które program starał się zniwelować zmianami kursu rakiety. W rezultacie wydano polecenie samozniszczenia rakiety ze względu na anomalie w jej locie.

- Advertisement -

“Podobne przypadki zdarzały się w dotychczasowej historii misji kosmicznych i choć większość specjalistów nie ma na co dzień związków z branżą kosmiczną, to doświadczenia wyniesione z analizy tych przypadków są cenną lekcją. Przypominają o konsekwencjach, które mogą pojawić się również w naszych projektach przy okazji błahych pomyłek. Co istotne, choć mówimy o szeregu przyczyn lub sytuacji, w której błąd decydujący o katastrofie może pojawić się na dalszych etapach realizacji projektu, to niemal zawsze możemy wskazać praprzyczynę. Z perspektywy Quality Assurance musimy pamiętać, że często to właśnie ów pierwszy punkt, który nie został zrealizowany prawidłowo, prowadzi do ostatecznego niepowodzenia.”

Agnieszka Skokowska, Principal QA Leader w Inetum Polska

Przykłady zaczerpnięte z misji kosmicznych są wartościowe również z uwagi na fakt, iż sektor Space pozostaje jednym z motorów napędzających rozwój technologii, które z czasem były wdrażane w innych branżach, np. w lotnictwie. Branża Aerospace jest jedną z tych, które chętnie korzystają z technologii IT. Informacje o stanie statku powietrznego, jego urządzeniach pokładowych i innych komponentach jest niezbędna w czasie rzeczywistym. Analiza milionów próbek danych, miliardów statusów urządzeń w lotnictwie nie jest możliwa bez wsparcia sztucznej inteligencji. Jednak nie można na niej polegać całkowiecie.

“W Inetum posiadamy własne rozwiązania testowe i zespoły R&D, co pozwala nam sprawniej i odpowiedzialniej dostarczać nowe rozwiązania czy modyfikować istniejące systemy. W obszarze Quality inetum.com Inetum Headquarters, 145 boulevard Victor Hugo, 93400 Saint-Ouen – FRANCE ©2022 Inetum Assurance korzystamy z najlepszych praktyk, m.in. tych stosowanych w branży kosmicznej. De facto realizacja żadnej z misji kosmicznych nie byłaby możliwa bez wsparcia zaawansowanych technologicznie urządzeń, których pracą steruje napisany z myślą o tym program. Opisane przypadki pokazują, z jakimi rodzajami błędów mieliśmy do czynienia i stanowią cenną lekcję na przyszłość. Niezależnie od wszystkiego, to człowiek jest ostatnim ogniwem potwierdzającym jakość oprogramowania.”

Agnieszka Skokowska

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.

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.

“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ż. 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.”

Agnieszka Skokowska, Principal QA Leader w Inetum Polska

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 inetum.com Inetum Headquarters, 145 boulevard Victor Hugo, 93400 Saint-Ouen – FRANCE ©2022 Inetum 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ę inetum.com Inetum Headquarters, 145 boulevard Victor Hugo, 93400 Saint-Ouen – FRANCE ©2022 Inetum 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.

SOURCES:Grupa Inetum
Udostępnij
Leave a comment

Dodaj komentarz

- REKLAMA -