Patriot chybił Scuda, bo maleńki błąd reprezentacji czasu narastał przez wiele godzin
W 1991 r. bateria Patriot w Dhahranie nie przechwyciła nadlatującego pocisku Scud; 28 żołnierzy USA zginęło. Raport GAO powiązał awarię z błędem oprogramowania w wyliczaniu czasu. System korzystał z wartości 0,1 sekundy reprezentowanej w ograniczonej binarnej precyzji. Takiego ułamka nie da się zapisać dokładnie w systemie dwójkowym, więc każde przeliczenie zawierało mały błąd. Po około 100 godzinach nieprzerwanej pracy błąd czasu urósł na tyle, że przewidywane położenie szybko lecącego Scuda było istotnie przesunięte.
0,1 wygląda dokładnie tylko w systemie dziesiętnym
W zapisie binarnym wiele prostych ułamków dziesiętnych ma rozwinięcie nieskończone, podobnie jak 1/3 w zapisie dziesiętnym. Komputer musi więc obciąć liczbę do dostępnej liczby bitów. Zwykle błąd jest mikroskopijny i praktycznie nieistotny. Problem pojawia się, gdy ten sam przybliżony krok jest używany do wyliczania bardzo dużego czasu od uruchomienia.
Błąd rósł wraz z uptime
Patriot nie był początkowo projektowany do wielodniowej, ciągłej obrony przed szybko lecącymi pociskami balistycznymi. W Dhahranie bateria działała około 100 godzin. Im większy licznik dziesiątych części sekundy, tym większa była łączna różnica między czasem reprezentowanym a rzeczywistym. GAO opisało, że po tak długim czasie rozbieżność osiągnęła około jednej trzeciej sekundy.
Jedna trzecia sekundy to dużo dla Scuda
Pocisk balistyczny porusza się z ogromną prędkością. Jeśli radar szuka celu w miejscu przewidywanym na podstawie czasu przesuniętego o setne lub dziesiąte sekundy, okno śledzenia może znaleźć się setki metrów od rzeczywistej pozycji. System może wówczas uznać, że wykryty sygnał nie jest oczekiwanym celem i nie przeprowadzić przechwycenia.
To nie był „błąd floating point” w dzisiejszym sensie jednego typu
Popularne opisy mówią czasem po prostu o floating point. GAO opisywało konkretny sposób reprezentacji i obcinania wartości używanej do przeliczania dziesiątych części sekundy. Ważniejsza od etykiety jest zasada: przybliżenie numeryczne, które jest bezpieczne przez kilka godzin, może stać się niebezpieczne po długim czasie pracy.
Poprawka istniała, ale dotarła za późno
Army i producent pracowali nad poprawkami zwiększającymi dokładność dla długiego czasu pracy. Zmodyfikowane oprogramowanie dotarło do Dhahranu dzień po ataku. To przypomina, że bezpieczeństwo systemu zależy również od dystrybucji aktualizacji i wiedzy operatorów o ograniczeniach istniejącej wersji.
Testuj granice czasu, nie tylko bieżący moment
Programista często testuje system kilka minut lub godzin. Błędy związane z licznikiem czasu ujawniają się po dniach, miesiącach albo latach. Patriot jest klasycznym argumentem za accelerated testing: można sztucznie ustawić licznik na dużą wartość i sprawdzić zachowanie bez czekania stu godzin. W systemie długo działającym warto również rozdzielić czas absolutny od czasu względnego. Zamiast mnożyć ogromny licznik ticków przez niedokładny współczynnik przy każdej operacji, można okresowo synchronizować stan z dokładniejszym źródłem i wykonywać krótkookresowe różnice na mniejszych liczbach. To ogranicza narastanie błędu i upraszcza analizę granic.
Stałoprzecinkowa arytmetyka także wymaga analizy błędu
System Patriot powstał w epoce, gdy koszt sprzętu i wymagania czasu rzeczywistego silnie wpływały na wybór reprezentacji liczb. Stosowanie ograniczonej liczby bitów nie jest samo w sobie błędem. Problem pojawia się wtedy, gdy projektant nie policzy, jak błąd kwantyzacji rośnie w najdłuższym możliwym scenariuszu pracy. Dla każdego przybliżenia numerycznego można oszacować maksymalny błąd pojedynczej operacji, a następnie sprawdzić jego akumulację w czasie. Jeśli wynik staje się nieakceptowalny po 20, 50 czy 100 godzinach, system może okresowo zerować punkt odniesienia, stosować reprezentację o większej precyzji albo używać algorytmu, w którym błąd nie kumuluje się liniowo. To ważna lekcja dla współczesnego embedded software: ograniczona precyzja jest normalna, ale musi być elementem analizy bezpieczeństwa, a nie ukrytym szczegółem implementacji.