Drobny błąd w oprogramowaniu, poważne konsekwencje

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.

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 że 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 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ów 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.

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. 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 do Ariane-4. Nie było też 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ę Czerwonej 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ż sonda Mars Climate Orbiter spłonęła w atmosferze planety. 25 września  agencja 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 kodu, tworzony w Anglii na zlecenie Lockheed Martin pisany był bowiem w oparciu o inne jednostki metryczne niż część opracowana w Stanach Zjednoczonych 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.

Skąd biorą się luki w oprogramowaniu? Szukając odpowiedzi na to pytanie należy zacząć od prehistorii, która wytyczyła sposób projektowania oprogramowania. W tym wypadku musimy cofnąć się przynajmniej kilka, kilkanaście lat.

Początkowo, systemy operacyjne ani aplikacje nie były projektowane, by być bezpieczne, tylko by wykonywały swoje zadania szybko. Kiedy zdecydowano się na wprowadzenie mechanizmów bezpieczeństwa, miały one na celu separację użytkowników systemu między sobą, a nie separację i izolację programów wykonywanych przez jednego użytkownika. Dlatego też, najpopularniejszy model systemów operacyjnych to duże jądro systemu z najwyższymi uprawnieniami oraz bardzo wysokie (acz niepotrzebne z praktycznego punktu widzenia) uprawnienia dla wykonywanych programów. 

Był to, jak się szybko okazało, wynik nieaktualnych już założeń, że wiele osób będzie korzystało z tego samego OS-u. Szybko straciły one moc, ponieważ zamiast współdzielić oprogramowanie, coraz częściej to pojedyncze osoby pracują na wielu systemach jednocześnie, przykładowo, korzystając z laptopa, smartfona i tabletu. Przy takim podejściu, należałoby przenieść nacisk z odizolowania od siebie użytkowników tej samej maszyny na odizolowanie aplikacji, czego zresztą jesteśmy od niedawna świadkami.

Błędy w oprogramowaniu to jednak nie tylko owoc założeń nie dorastających do rzeczywistości. Winą obarczyć można często krótkodystansowe cele. Zamówione oprogramowanie ma być bowiem dostarczone na czas i ma działać. Nikt 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. Skomplikowane rzeczy psują się bowiem w skomplikowany sposób.

To o czym mowa to też pochodna braku odpowiedzialności za błędy w oprogramowaniu. Niezależnie od zobowiązania poprawienia ewentualnych błędów w oprogramowaniu, które pojawią się w trakcie użytkowania produktu, wszyscy producenci oprogramowania zastrzegają sobie brak odpowiedzialności za szkody wyrządzone przez ich software.

Skoro brak bezpośredniego przełożenia błędów w oprogramowaniu na koszty, które mogą być ich skutkiem, nacisk kładzie się głównie na dostarczenie funkcjonalności oprogramowania, a nie na jakość kodu, czy czystą i dobrze zaprojektowaną architekturę rozwiązania. Stąd też często brak dyscypliny i dbałości o jakoś oprogramowania. Kiedy testom podlega tylko zamówiona funkcjonalność, bardzo rzadko wykonywany jest też profesjonalny audyt kodu. Coś bez czego w branży IT Security, w której funkcjonuje WHEEL Systems nie sposób się obejść. Aplikacje i systemy, mające na celu zabezpieczenie danych lub infrastruktury informatycznej muszą być dobrze napisane i przejść szczegółowe audyty.

Brak odpowiedzialności finansowej to jednak nie wszystko. Swoje dokłada tu też presja czasu i brak kompetencji niektórych programistów spowodowany brakiem rzetelnej edukacji z silnym naciskiem na aspekty bezpieczeństwa. Pojawiają się pomysły kopiowania kodu z innych, podobnych rozwiązań bez sprawdzenia jego rzeczywistej przydatności i spójności lub nadpisywanie nowego kodu na starej bazie, nie myśląc o konsekwencjach takiego działania. Żeby zobrazować do czego może doprowadzić taka niedbałość, wystarczy wspomnieć katastrofalny start rakiety ESA Arianne-5. Zbędny fragment kodu z poprzedniej wersji oprogramowania sterującego sprawił, że eksplodowała ona jeszcze w pierwszej fazie lotu. Nie licząc czasu potrzebnego na przygotowanie misji, kosztowało to ESA ponad pół miliarda dolarów.