Jak drobny błąd spowodował katastrofę (i co to ma wspólnego z Tobą)?

W lutym 1991 podczas I wojny w Zatoce Perskiej jednej z baterii rakiet Patriot nie udało się przechwycić wystrzelonych przez siły irackie rakiety Scud. W efekcie zginęło 28 osób, a 100 innych zostało rannych. Samo to nie jest jednak tutaj najważniejsze. O ile utrata każdego życia ludzkiego jest tragedią to nie można oczekiwać, że systemy techniczne będą zawsze dobrze realizowały swoje zadania. Tym razem okazało się jednak, że zawinił pewien drobny błąd popełniony przez inżynierów, którzy przygotowali oprogramowanie systemu. Analizując tę sytuację można wyciągnąć bardzo ważne wnioski na temat tego kim jest i czym powinien się charakteryzować dobry inżynier.

Co się stało w Zatoce Perskiej

System odpowiadający za wystrzelenie rakiet Patriot działał w oparciu o wyznaczenie pozycji, w której znajdzie się rakieta Scud w momencie dogodnym do zestrzelenia. Wyznaczenie tej pozycji wymagało znajomości pozycji i prędkości rakiety podczas ostatniej detekcji na radarze oraz chwili czasu, w której ta detekcja nastąpiła.

W opisywanej sytuacji zawiódł właśnie pomiar czasu, a dokładnie skończona reprezentacja binarny liczb niecałkowitych. System Patriot wyposażony był w wewnętrzny zegar, który odliczał czas co 0,1 s. Ta wartość, czyli 0,1 s, była co każdy takt zegara dodawana do stanu licznika, który odmierzał czas od uruchomienia systemu.

Rakiety Patriot. Źródło: Wikipedia.

Jak każdy programista powinien wiedzieć – liczby 0,1 s nie da się zapisać dokładnie w systemie binarnym. Zachodzi tutaj ten sam efekt, co podczas próby zapisania liczby 1/3 jako ułamka dziesiętnego – jej rozwinięcie ma nieskończenie wiele cyfr i każdy fizyczny zapis musi się skończyć jakimś przybliżeniem.

W przypadku systemu Patriot błąd tego przybliżenia wynosił około 1 mikrosekundy. Wydaje się to niedużą wartością, ale system działał od uruchomienia przez ponad 100 godzin i całkowity błąd skumulował się do wartości ok. 0,34 s. Samo to nie byłoby jeszcze problemem (gdyż nie jest ważny czas bezwględny, ale różnica między czasem wykrycia a czasem zestrzelenia rakiety). Niestety okazało się, że w niektórych częściach oprogramowania błąd był korygowany, a w innych nie. W efekcie pozycja rakiety Scud została obliczona błędnie o mniej więcej pół kilometra, co wystarczyło, żeby rakieta Patriot nie mogła jej namierzyć. 

Co z tego wynika?

Wydaje mi się, że ten przykład dobrze pokazuje czym powinien się charakteryzować dobry inżynier. Chodzi tu konkretnie o dobre rozumienie szczegółów działania projektowanego przez siebie systemu i umiejętność oceny które z nich i w jakich warunkach mogą odgrywać znaczenie.

Spójrzmy prawdzie w oczy. W dobie programowania wysokopoziomowego i gotowych frameworków pozwalających na szybkie tworzenie efektownych aplikacji ilu twórców oprogramowania jest w ogóle świadomych takich problemów jak błędy zaokrągleń w arytmetyce binarnej?

Jeżeli zajmujesz się programowaniem to zastanów się czy wiesz jak są reprezentowane liczby zmiennoprzecinkowe w standardowym formacie double i jaka jest dokładność takiej reprezentacji?

 

Oczywiście to tylko przykład, a tego typu „szczegółów” w pracy inżynierskiej jest całe mnóstwo (być może postaram się niedługo kilka opisać). Dobry inżynier potrafi balansować między dwoma skrajnościami. Z jednej strony musi znać wszystkie zjawiska, efekty i zasady, które wpływają na pracę projektowanych przez niego systemów. Z drugiej – nie może utknąć w gąszczu teorii i równań, z których niewiele wynika.

Oznacza to, że studiując, pracując i rozwijając się jako inżynier możesz wpaść w jedną z dwóch pułapek. Pierwsza z nich jest dość dobrze znana: Skupiasz się tylko na zdobywaniu wiedzy teoretycznej i zapamiętywaniu faktów, a zaniedbujesz naukę ich praktycznego wykorzystywania. Dzieje się tak, niestety, w przypadku wielu studentów politechnik, którzy dopiero po studiach zaczynają odkrywać jak wygląda „prawdziwy świat”.

Jednak możesz też przesadnie skupić się tylko na tym dla czego widzisz bezpośrednie zastosowanie, a zaniedbać zdobywanie dobrze ugruntowanej wiedzy na temat swojej dziedziny. Ostatecznie po co masz zajmować się czymś tak abstrakcyjnym jak reprezentacja liczb zmiennoprzecinkowych? Niestety, ryzykujesz sytuacją, w której przez brak świadomości jakiegoś problemu nawet nie będziesz wiedział że możesz popełnić w swoim projekcie błąd. Efekty takich błędów widziałem wiele razy. Nie były one tak katastrofalne jak w przypadku rakiet Patriot ale kończyły się zniszczonym sprzętem, wieloma dniami analiz i opóźnieniami w realizacji projektów.

Kilka uwag na koniec

Uważam, że dobry inżynier powinien poświęcić wiele wysiłku w celu zrozumienia podstaw działania różnych systemów technicznych, a także matematyki i fizyki (w różnych proporcjach – w zależności do swojej specjalności). Dzięki temu nie będą umykać Ci żadne „błędy zaokrągleń”. Sam staram się nieustannie poszerzać swoją wiedzę i zachęcam Cię do tego samego.

Warto jeszcze podkreślić, że inżynierowie zajmujący się systemem Patriot mieli świadomość problemu nieskończonego rozwinięcia dziesiętnego liczby 0,1. Ostatecznie system zawiódł dlatego, że wprowadzili poprawki tego efektu, ale pominęli niektóre części oprogramowania. Wygląda więc na to, że zadziałał tutaj raczej mechanizm złej architektury oprogramowania i nie wystarczającego testowania, znany pewnie większości programistów. Jeżeli chcesz poczytać więcej o tej sprawie to możesz zacząć od zajrzenia pod link: http://www-users.math.umn.edu/~arnold//disasters/patriot.html

No i już na sam koniec, skoro mówimy o reprezentacji binarnej liczb zmiennoprzecinkowych, to wrzucam dwa filmy z naszego kursu „Podstawy programowania. Język C” poświęcone właśnie temu tematowi. Cały kurs (oraz materiały dla bardziej zaawansowanych) możesz znaleźć na naszej platformie: https://kursy.intertechacademy.pl/

 

Maciej Kraszewski

Maciej Kraszewski

Inżynier, menedżer R&D i nauczyciel akademicki. Uwielbiam zajmować się tworzeniem nowych technologii, zdobywaniem nowej wiedzy i dzieleniem się swoim doświadczeniem z innymi. Specjalizuję się w zagadnieniach przetwarzania obrazu i widzenia maszynowego.
Szukasz dobrych materiałów o projektowaniu elektroniki?

Załóż darmowe konto na naszej platformie i odbierz pakiet materiałów edukacyjnych.

Zakładając konto zgadzasz się na przesyłanie Ci treści marketingowych przez IT20 sp. z o.o. zgodnie z dostępną na stronie Polityką Prywatności. Możesz wycofać zgodę w każdej chwili.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Szukasz dobrych materiałów o projektowaniu elektroniki?

Załóż darmowe konto na naszej platformie i odbierz pakiet materiałów edukacyjnych.

Zakładając konto zgadzasz się na przesyłanie Ci treści marketingowych przez IT20 sp. z o.o. zgodnie z dostępną na stronie Polityką Prywatności. Możesz wycofać zgodę w każdej chwili.

Zaprojektuj PCB

Jak przejść od zera do projektowania profesjonalnych obwodów drukowanych?

Programowanie w języku C

Jak przejść od napisania pierwszego programu komputerowego do wykorzystania zaawansowanych metod programowania?

Projektowanie układów elektronicznych

Jak działają i jak projektować poprawnie działające układy elektroniczne?
Zapisz się na listę mailową i odbierz swoje bonusy!

Więcej treści na temat elektroniki i robotyki, darmowe e-booki i dostęp do minikursów on-line. Otrzymasz to wszystko zapisując się na naszą listę mailową.