Postęp technologiczny, o którym słyszy się na co dzień przejawia się w większym stopniu w stale rosnącej puli otaczającego nas oprogramowania, niż w wykorzystaniu nowych materiałów i oryginalnych koncepcjach konstrukcyjnych. Niezawodność nowoczesnych urządzeń uzależniona jest jednak od czynnika ludzkiego, jakim niewątpliwie są osoby tworzące oprogramowanie. Pisaniem software’u zajmują się jednak profesjonaliści. Co więc sprawia, że wciąż odkrywane są kolejne błędy?

„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, w której działa Wheel Systems.” – 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.”

Na to natomiast, że błędy w oprogramowaniu potrafią doprowadzić nie tylko do wyświetlenia legendarnego błękitnego ekranu, ale i do znacznie poważniejszych konsekwencji – liczonych ludzkim życiem i miliardami dolarów – dowodów nie brak.

Mateusz Kocielski, odpowiedzialny w LogicalTrust za testy bezpieczeństwa twierdzi, że „błędy w są wszędzie, ponieważ oprogramowanie jest wszędzie” i wymienia kilka przykładów, w których niewielkie przeoczenia programistów, chęć zaoszczędzenia czasu, czy też zwyczajny brak możliwości przewidzenia wszystkich ewentualności, doprowadziły do opłakanych skutków.

1. Therac-25

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. Ogółem jednak, zabrakło jednego, jak się okazało, niezmiernie istotnego wiersza kodu. Raptem kilkudziesięciu znaków.

Z drugiej strony, błąd z dużym prawdopodobieństwem zostałby wychwycony przed wprowadzeniem produktu na rynek, gdyby nie zabrakło rzetelniejszej procedury testowej.

2. Patriot

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 tych, w celu zwalczania radzieckich rakiet, poruszających się przeciętnie z prędkością około 2 MACH. 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 system wykorzystywał w procesie namierzania pocisków wroga własny czas pracy w sekundach. Niestety, z pewnych względów, dokładność obliczeń zmiennoprzecinkowych, wykonywana w tym celu, była daleka od ideału. W efekcie, 1 sekunda wyliczana przez baterię nie była równa rzeczywistej sekundzie. Po 100 godzinach pracy, system mylił się 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 irackiej rakiecie scud, mimo wychwycenia jej na planie nieba, a następnie namierzeniu 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 dopuszczając 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.

3. Ariane-5

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.

4. 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 softwareu, 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 o 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.

Czy błędów w oprogramowaniu będzie coraz więcej?

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.