4 największe katastrofy programistyczne w historii - drobne błędy o tragicznych konsekwencjach

Na błędy i awarie oprogramowania natknął się chyba każdy, kto korzysta z nowoczesnych technologii. Narażeni jesteśmy na nie podczas używania komputerów, nowoczesnych komórek, ostatnimi czasy nawet telewizorów czy samochodów. W większości przypadków konsekwencje zawieszenia się programu czy wyświetlenia nieoczekiwanego komunikatu nie są zbyt poważne. Ot, trzeba ponownie uruchomić program, wyjść z aplikacji czy w najgorszym wypadku wyłączyć urządzenie. Zdarza się jednak, że błędy programistów prowadzą do znacznie poważniejszych skutków.

- Za błędy w oprogramowaniu często winą obarczyć można krótkodystansowe cele biznesowe. Zamówione oprogramowanie ma być bowiem dostarczone na czas i ma działać. Testuje się jednak tylko tę nową funkcjonalność, nie sięgając po profesjonalny audyt całego kodu. To nie do przyjęcia w branży IT Security – zauważa Paweł Dawidek, dyr. ds. technicznych i oprogramowania w Wheel Systems. – Co więcej, nikt też nie patrzy na jakość kodu, a co za tym idzie, na łatwość utrzymania i rozwijania oprogramowania. Im gorsza jego jakość, im kod jest bardziej skomplikowany i nieczytelny, tym więcej ma błędów i są one trudniejsze do znalezienia podczas testów. Sprawia to, że dużo łatwiej jest wprowadzić nowe błędy podczas rozwoju tak skonstruowanego oprogramowania. Poza tym, im czystszy kod, tym ewentualne błędy prostsze w naprawie. Bo skomplikowane rzeczy psują się w skomplikowany sposób.

A na to, jak poważne mogą być konsekwencje błędów oprogramowania, dowodów nie brak.

Między 1985 a 1987 rokiem 6 osób uległo poparzeniu w wyniku naświetlań maszyną Therac-25. Trzy z nich zmarły w następstwie wypadku.

W trakcie pierwszego wypadku, w wyniku którego pacjentka straciła pierś i czucie w ręce, okazało się, że automat zaaplikował ok. 100 razy większą dawkę promieniowania, niż wynikało ze zlecenia. Producent, firma AECL uznała jednak, że to niemożliwe, nie podjęto więc żadnych działań.

Jeszcze w tym samym roku – w 1985 r. – inna maszyna uległa awarii, wyświetlając komunikat o błędzie i niepodjęciu naświetlania. Operator, przyzwyczajony do humorów urządzenia, wymusił wykonanie procedury. Maszyna pięciokrotnie podejmowała próbę wykonania naświetlenia, po czym zupełnie odmówiła posłuszeństwa. 3 miesiące później pacjent, który brał udział w zabiegu, zmarł w związku z powikłaniami napromieniowania.

AECL bardzo długo wypierało się winy, uznając, że nie istnieje możliwość, aby Therac-25 mylił dawki, albo wykonał naświetlania mimo przeczącego temu komunikatowi. Mimo to poparzeniom uległo jeszcze kilka osób, a sprawa trafiła do sądu. W toku postępowania rzecznik AECL przyznał, że wykonano ”małą liczbę” testów urządzenia nim trafiło na rynek.

Jak się okazało, wart ponad 1 mln dolarów automat został wyposażony w napisane w assemblerze oprogramowanie, stworzone przez jedną osobę. Wypadki powodowały dwa drobne przeoczenia programisty. Zabrakło jednego, jak się okazało, niezmiernie istotnego wiersza kodu. Raptem kilkudziesięciu znaków.

Podczas Wojny w Zatoce Perskiej w 1991 roku iracka rakieta Scud trafiła w amerykańskie baraki w Dhahran, zabijając 28 osób i raniąc ponad 100. Doszło do tragedii, mimo iż bezpieczeństwa bazy pilnowało aż 6 baterii systemu przeciwrakietowego Patriot.

Wyjaśniając kulisy wypadku, należy podkreślić, że Patriot stworzono w latach 70. w celu zwalczania radzieckich rakiet, poruszających się przeciętnie z prędkością około 2 machów. Dodatkowo, w założeniach, system miał być wysoce mobilny. Czas ciągłej pracy przewidywano więc na nie więcej niż 8 godzin. Po tym okresie miał on być dezaktywowany, przewożony i uruchomiany ponownie w nowym miejscu.

Jak się okazało, w związku z długim procesem aktywowania się systemu (60-90 sekund), amerykańskie baterie w Iraku działały bez przerwy nawet ponad 100 godzin. Nie byłoby to problemem, gdyby nie fakt, że jedną ze zmiennych wykorzystywanych w obliczeniach był właśnie czas pracy w sekundach. Dokładność działań zmiennoprzecinkowych, wykonywanych do namierzania celów, była zaś daleka od ideału. W efekcie 1 sekunda wyliczana przez baterię nie była równa rzeczywistej sekundzie, a błąd kumulował się z czasem. Nie stanowiło to problemu, jeżeli system nie działał zbyt długo. Ale po 100 godzinach pracy mylił się on już o 0,34 sekundy.

Pomyłka ta okazała się wystarczająca, aby pozwolić wymknąć się lecącej z prędkością aż 5 machów irackiej rakiecie Scud, mimo wychwycenia jej na planie nieba, a następnie namierzenia w pierwszej fazie celowania. Posługując się niedokładnym zegarem, system błędnie wyliczył okno, w którym powinna się pojawić wroga rakieta w drugiej fazie namierzania. Nie zastawszy w nim oczekiwanego obiektu, Patriot nie podjął żadnych działań, uznając, że to fałszywy alarm. W efekcie doszło do tragedii.

Oficjalną przyczyną incydentu jest niewłaściwa eksploatacja systemu Patriot. Nie przewidziano, że baterie będą aktywne przez 100 godzin bez przerwy. Wina leży jednak także po stronie programistów, którzy o powstającym odchyleniu czasu dowiedzieli się dopiero na krótko przed wydarzeniami w Dhahran.

10 lat i 7 miliardów dolarów. Tyle trwał i kosztował projekt budowy rakiety Ariane-5, która przez błąd w oprogramowaniu rozpadła się na oczach zaskoczonych widzów kilkadziesiąt sekund po starcie. Europejska Agencja Kosmiczna postanowiła zbudować rakietę większą, szybszą i lepszą od poprzedniczki – Ariane-4. Właśnie to dziedzictwo zaważyło na katastrofie. Okazało się, że część oprogramowania nowej rakiety skopiowano ze starej. W trakcie lotu jedna z funkcji pochodzących z Ariane-4, a w nowej rakiecie zupełnie zbędna, zgłosiła błąd. Jego interpretacja wprowadziła z kolei w błąd wewnętrzny system nawigacji rakiety, doprowadzając tym samym do wydania przez główny komputer polecenia wykonania nagłego zwrotu o 20 stopni. W tym wypadku nie pomógł nawet awaryjny system, ponieważ kiedy główny komputer, w wyniku błędu, wyłączył się, zapasowy obwód, który powinien przejąć jego zadania, też już nie działał.

W toku śledztwa wyszło na jaw, że nie sprawdzono dokładnie założeń oprogramowania Ariane-4, na którym budowano software do Ariane-5. Nie było też systemu testów, ani nie przeprowadzono symulacji programowej.

NASA Mars Climate Orbiter

Po 10 miesiącach lotu, 23 września 1999 roku sonda warta około 700 mln dolarów dotarła w pobliże Marsa. O godzinie 8.41 UTC rozpoczęto manewr wchodzenia na orbitę planety. O 9.04, zgodnie z planem, sonda znalazła się po drugiej stronie Marsa, tracąc chwilowo kontakt z kontrolą lotów. Połączenie nie zostało już jednak nigdy odzyskane, ponieważ MCO spłonęła w atmosferze planety. 25 września NASA przyznała się do niepowodzenia.

Śledztwo wykazało, że wątpliwości dotyczące powodzenia misji MCO pojawiły się już wcześniej, ale zostały zignorowane. Bezpośrednim powodem porażki okazał się jednak brak komunikacji między zespołami, tworzącymi oprogramowanie do MCO. Fragment software'u, tworzony w Anglii na zlecenie Lockheed Martin, pisany był bowiem w oparciu o inne jednostki metryczne niż część opracowana w USA przez NASA. Kiedy wychwycono niespójność jednostek, alarm został zignorowany. Błąd okazał się jednak na tyle poważny, że doprowadził do nieprawidłowej pracy dopalaczy lądownika. Konsekwencją tego było zbyt bliskie podejście, a co za tym idzie, spalenie się sondy w atmosferze Marsa.

To tylko cztery spektakularne przykłady, ilustrujące do czego mogą doprowadzić nawet drobne błędy i przeoczenia w oprogramowaniu. Tragedie w przeróżnej skali wydarzają się codziennie. Ofiarami słabej jakości kodu padają miliony ludzi, czasem nawet nie zdając sobie z tego sprawy, a liczba ta wciąż rośnie. Wynika to z prostego faktu - otacza nas coraz więcej oprogramowania i nic nie zapowiada, aby ten trend miał się zmienić. Tym bardziej, że prawie każdy nosi w kieszeni kilka milionów linii kodu – telefon komórkowy.

Polecamy w wydaniu internetowym chip.pl: Polscy studenci zdominowali prestiżowy konkurs inżynierski w USA