Ciekawostki

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

Czasem nawet najdrobniejsze niedopatrzenie może przynieść katastrofalne konsekwencje.

BSOD

Owocem błędów w oprogramowaniu może być, na przykład, niebieski ekran śmierci. To jednak ta optymistyczna wersja. Mogą one bowiem również prowadzić do znacznie poważniejszych konsekwencji – także takich liczonych ludzkim życiem i miliardami dolarów. Przykładów nie trzeba zresztą szukać daleko. Odpowiedzialny za testy bezpieczeństwa w LogicalTrust Mateusz Kocielski twierdzi, że „błędy są wszędzie, ponieważ oprogramowanie jest wszędzie” i wymienia kilka przykładów, w których do katastrofalnych skutków doprowadziły na pozór niewielkie przeoczenia programistów, chęć zaoszczędzenia czasu lub po prostu brak wyobraźni.

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. 

Therac-25

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. 

Patriot

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.

Ariane-5


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. 

MCO

Ś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.

To tylko cztery przykłady, ale bardzo wyraźnie podkreślają one, że nawet najdrobniejsze błędy i przeoczenia podczas tworzenia oprogramowania mogą doprowadzić do tragedii. Oczywiście jest to nieuniknione – nikt z nas nie jest nieomylny. Warto jednak mieć świadomość, że ofiarami słabej jakości kodu mogą stać się także ludzie. Ta wiedza bowiem może zmotywować programistów do jeszcze uważniejszej pracy, która wszystkim nam wyjdzie na dobre. 

Dyrektor ds. Technicznych i Oprogramowania WHEEL Systems, Paweł Dawidek przygotował komentarz w tej sprawie, który możecie przeczytać poniżej:

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. 

kod html

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.

programista

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.

Źródło: Wheel Systems, LogicalTrust, Identi, Wikimedia, inf. własna

Komentarze

19
Zaloguj się, aby skomentować
avatar
Komentowanie dostępne jest tylko dla zarejestrowanych użytkowników serwisu.
  • avatar
    Kerebron
    2
    Sednem artykułu są nie tyle jakiekolwiek błędy, co szczególny ich typ, czyli zaniedbania. Błędy się zdarzają, są nieuniknione i zupełnie naturalne. Zaniedbań natomiast można i należy unikać za wszelką cenę. Błąd nie zawsze jest zawiniony przez kogoś (jak mawiali starożytni rzymianie ;) "honest mistake"), za to zaniedbanie zawsze ma "właściciela", który powinien ponieść konsekwencje swojego czynu.
    • avatar
      shamoth
      2
      Rozumiem że jest to "artykuł reklamowy" w związku z ostatnim Batmanem, mający na celu uświadomić nam że niechlujstwo może mieć bardziej katastrofalne skutki???
      • avatar
        Konto usunięte
        1
        Może się czepiam, ale strasznie mnie wkurza, kiedy autorzy artykułów czerpiąc z anglojęzycznych źródeł, nie przykładają się do tłumaczenia. Już piszę o co mi chodzi: w drugim przykładzie, dotyczącym błędu w oprogramowaniu systemów Patriot, autor napisał, że "rakieta scud trafiła w amerykańskie baraki". No i co z tego? Przecież w barakach to zazwyczaj trzyma się sprzęt budowlany, przebierają się robotnicy itp, ale nikt w nich nie przebywa na stale. A już zwłaszcza żołnierze w bazie wojskowej, wiec jakim cudem zginęło 28 osób a 100 zostało rannych? Już tłumaczę - w wyniku błędu w tłumaczeniu autora artykułu a nie błędu w oprogramowaniu. Po prostu angielskie słowo "barracks" to nie nasze swojskie baraki, ale KOSZARY, panie redaktorze.
        • avatar
          carbo888
          0
          Moim zdaniem wiele błędów w oprogramowaniu wynika u informatyków z braku wiedzy na tematy nie dotykające problematyki ich zawodu. Tzn. Fizyk dla którego ma być program zna się na fizyce itd. ale nie ma bladego pojęcia o programowaniu i vice versa u informatyka, zna się na programowaniu ale za to ma bardzo znikomą wiedzę na temat fizyki (tak w uproszczeniu). Taka sytuacja nawet gdy programista z fizykiem prowadzi konsultacje to wiele informacji może być ominiętych, zapomnianych, niezrozumiałych itp. ze względu na różnicę np. w profesjolekcie. Musi minąć wiele lat zanim specjaliści z różnych branż nie tylko będą się znać na swojej profesji lecz będą znali też język maszyn.
          • avatar
            Konto usunięte
            0
            Głównym powodem błędów jest ogrom kodów, ktoś nie wiedzący nic o programowaniu może stwierdzić że da się to przetestować. Jednak jest to nie prawda programy często mają ponad 10 tysięcy linijek kodu. Wyłapanie błędu nie wynikającego z odstępstwem od standardu języka najczęściej jest prawie nie wykonalne. Nie raz przez głupie błędy piszę się cały program od nowa. A niektóre błędy mogą ujawnić się tylko raz na miliard i być praktycznie nie wykrywalne testami.
            • avatar
              Konto usunięte
              -24
              Bzdura. Co prawda nie wiem jak w PL pisze sie kod (biorac pod uwage ze brak polskich uczelni chocby w top500 uczelni to moze jednak moze byc prawda) ale w UK czy US testowanie kodu jest na porzadku dziennym, nie wyobram sobie pisania czegokolwiek bez testowania. Jest to nierealne. Na studiach w UK kladli na to bardzo duzy nacisk.

              Art bzdurny bo ma pokazac na przykladzie skrajnym, jak ta firemka liliput (dziala poza PL czy tylko w okolicach Krakowa ;)) niby prowadzi audyty swojego oprogramowania...

              Maja chocby ISO z BSI ??? Gledzebie bandy biedakow aby troche grosza od Polskiego konsumenta wyslupac.
              • avatar
                sid vicious
                0
                Owocem błędów w oprogramowaniu może być, na przykład, niebieskie ekran śmierci.

                Do edycji. Czytajcie co piszecie.
                • avatar
                  MarTum
                  0
                  Uczymy się na błędach. Tyle.
                  • avatar
                    Konto usunięte
                    0
                    Błędy w oprogramowaniu zawsze będą. Nie spotkałem się jeszcze z oprogramowaniem, które pozbawione by było jakiejkolwiek aktualizacji (wiąże się to przeważnie z naprawieniem błędów wykrytych już przez użytkowników). Sam trochę programuje i wiem jak trudno jest nieraz znaleźć błąd w kodzie jednak uważam, że niektóre sektory powinny mieć wymóg stosowania dodatkowych testów w swoich aplikacjach. Mówię tutaj o wspomnianych w artykule urządzeniach medycznych, sprzęcie wojskowym a także urządzeniach powszechnego użytku, które mogą zagrażać życiu człowieka typu winda itd.
                    • avatar
                      AveJA852
                      0
                      Dlatego samemu trzeba testować(nowsze nie znaczy lepsze) za to na pewno kod jest dłuższy.Za każdym razem kiedy wychodzi update myślę sobie ciekawe jakie bugi dodali.Oczywiście mówię tu o rzeczach tanich.Bo im sprzęt droższy tym bardzie zabezpieczony i koniec końców tylko producent może ten błąd wykryć ale po sprzedaniu woli liczyć że bóg sprawi cud i 80-90% sprawności wystarczy żeby sprzęt działał w 100%.Takie czasy.