Dzisiaj opowieść o kolejnym znanym bugu, który miał ogromne konsekwencje. Podobnie jak w przypadku Therac-25, analiza katastrofy rakiety Ariane 5 przyczyniła się do poprawy procesów wytwarzania systemów safety-critical.
Jak wyglądał pierwszy lot Ariane 5?
We wtorek 4 czerwca 1996 roku odbył się dziewiczy lot Ariane 5 – nowej rakiety Europejskiej Agencji Kosmicznej, która była rozwijana przez ostatnie 10 lat, a budżet projektu wynosił 7 mld $. Rakieta miała wynieść na orbitę okołoziemską zespół sond do badania magnetosfery. Niestety pół minuty po starcie rakieta nagle przechyliła się o 90°, a siła aerodynamiczna spowodowała oderwanie się napędów rakietowych od reszty konstrukcji. Spowodowało to uruchomienie procedury autodestrukcji i eksplozję rakiety 4 km nad ziemią.
Błąd w kodzie
Przyczyną katastrofy był błąd w sofcie odpowiadającym za określanie pozycji rakiety w układzie współrzędnych. Zmienna przechowująca korektę prędkości w osi poziomej była konwertowana z 64-bitowej liczby float na 16-bitowego inta. Po 37 sekundach od startu zmienna ta osiągnęła wartość większą niż maksymalna liczba całkowita zapisana na 16 bitach. Nastąpił więc overflow i został zgłoszony exception. Moduł pozycji zamiast prawdziwej wartości podawał wartość oznaczającą błąd. Została ona zinterpretowana jako położenie i system nawigacji podjął decyzję o korekcie kursu. Co interesujące po wykryciu exceptiona moduł określania pozycji przestał działać i automatycznie uaktywnił się drugi, zapasowy moduł. Niestety oba moduł były identyczne i zawierały ten sam błąd.
Co interesujące – zmienna, która spowodowała problem nie była w ogóle potrzebna. Moduł estymacji pozycji przeniesiono z wcześniejszej wersji rakiety – Ariane 4. Feralna zmienna była w niej używana jedynie w momencie startu. Później podczas lotu przypisywano do niej nowe wartości, ale do niczego ich nie wykorzystywano. Ariane 5 natomiast miała zmienioną procedurę startu i nie musiała polegać na tej zmiennej. Była ona po prostu częścią martwego kodu, którego nikt nie usunął z nowej wersji modułu.
W Ariane 4 wykonano analizę ryzyka dla modułu pozycji i uznano, iż ta zmienna nie musi być chroniona przed overflowem. Moduł zawierał również wiele innych zmiennych, które posiadały taką ochronę. W tym wypadku jednak uznano, iż overflow nie jest możliwy dla parametrów fizycznych rakiety. Problem jednak polegał na tym, iż dla nowej wersji parametry fizyczne takie jak masa, szybkość, opór aerodynamiczny czy trajektoria lotu uległy zmianie.
Kod Ariane był napisany w języku ADA. Pełne źródła nie są publicznie dostępne, ale feralny fragment owszem:
Przyczyny błędu
Jednak raport analizujący przyczyny katastrofy, który ukazał się już dwa tygodnie po wypadku, wcale nie uznał samego buga w sofcie za źródło problemów:
The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift- off). This loss of information was due to specification and design errors in the software of the inertial reference system.
The extensive reviews and tests carried out during the Ariane 5 Development Programme did not include adequate analysis and testing of the inertial reference system or of the complete flight control system, which could have detected the potential failure.
Jako przyczyny wskazuje za to błędy w specyfikacji i designie powstałe przez brak odpowiedniej analizy ryzyka i testów. Są to więc błędy procesowe, a feralna linijka kodu jest tylko ich efektem:
- Decyzja o braku ochrony przed exceptionem dla tej zmiennej bez dostatecznej analizy i testów dla danych opisujących trajektorię lotu Ariane 5. Testy modułu pozycjonowania na symulatorze wykonane już po wypadku wykryły ten błąd. Wcześniejsze testy symulacyjne mockowały ten moduł.
- Obsługa exceptiona poprzez zresetowanie modułu nie nadawała się dla systemu estymacji pozycji. Aby określić aktualne położenie potrzebuje on informacji o wcześniejszym stanie. Tym bardziej, iż ta zmienna nie wpływała na działanie podstawowych funkcji modułu.
- Kod z poprzedniej wersji rakiety nie został wystarczająco przeanalizowany. Nie usunięto z niego nieużywanych funkcji.
- Architektura systemu umożliwiała przeciwdziałanie tylko błędom losowym wynikającym z awarii sprzętowych. Zakładała, iż software nie zawiera błędów systematycznych. Przez to redundancja w postaci drugiej jednostki obliczającej pozycję rakiety zawierała ten sam błąd.
Konsekwencje
Katastrofa spowodowała zainteresowanie opinii publicznej, polityków,organizacji rządowych i środowisk akademickich na całym świecie. Przeznaczono dodatkowe fundusze na badania metod poprawy bezpieczeństwa systemów safety-critical. Efektem było powstanie publikacji, norm oraz dobrych praktyk dotyczących tego typu urządzeń. Zwrócono również uwagę na rolę automatycznych tooli w analizie bezpieczeństwa np. do analizy statycznej.
