Jaki był historyczny wpływ lotu 501 Ariane 5?

Rozpad rakiety Ariane 5 37 sekund po starcie w jej dziewiczym rejsie ( Flight 501 ) jest powszechnie określany jako jeden z najdroższych błędów oprogramowania w historii ¹ :

Europejska Agencja Kosmiczna zajęła 10 lat i 7 miliardów dolarów, aby wyprodukować Ariane 5, gigantyczną rakietę, która z każdym wystrzeleniem może zrzucać na orbitę parę trzytonowych satelitów i zamierzała dać Europie przytłaczającą przewagę w komercyjnym biznesie kosmicznym.

Wystarczyło zaledwie kilka minut, by eksplodować tę rakietę w dziewiczą podróż w czerwcu ubiegłego roku, rozrzucając ognisty gruz na namorzynowych bagnach Gujany Francuskiej, to mały program komputerowy próbujący upchnąć 64-bitową liczbę w 16-bitową przestrzeń.

Jeden błąd, jedna awaria. Ze wszystkich nieostrożnych linii kodu zapisanych w annałach informatyki, ta może okazać się najbardziej niszczycielsko wydajna. Z wywiadów z ekspertami w dziedzinie rakiet i analizy przygotowanej dla agencji kosmicznej wyłania się wyraźna ścieżka od błędu arytmetycznego do całkowitego zniszczenia.

Jakie główne zmiany spowodowały awarię Flight 501 i kolejne badania zainspirowały do ​​badań systemów o krytycznym znaczeniu dla bezpieczeństwa i testowania oprogramowania?

Nie szukam wyjaśnienia samego błędu, ale wyjaśnienia historycznego wpływu błędu, w kategoriach badań, które zostały zainspirowane lub były bezpośrednio związane z dochodzeniem (badaniami) niepowodzenia. Na przykład ten artykuł zawiera następujące wnioski:

Zastosowaliśmy analizę statyczną, aby:

• sprawdź inicjalizację zmiennych,
• dostarczyć wyczerpującą listę potencjalnych konfliktów dostępu do danych dla zmiennych wspólnych,
• wyczerpująco wypisz potencjalne błędy w czasie wykonywania z semantyki Ada.

Według naszej wiedzy, po raz pierwszy do weryfikacji programów przemysłowych stosowane są techniki analizy statycznej oparte na logice i nie na bazie logiki.

Podobnie w tym dokumencie ^(pdf) odnotowano:

Do analizy statycznej wbudowanego oprogramowania ADA programu uruchamiającego Ariane 5 i ARD zastosowano analizę statyczną opartą na interpretacji abstrakcyjnej. Statyczny analizator programów ma na celu automatyczne wykrywanie niedokładności, potencjalności, niemożliwości lub niedostępności błędów w czasie wykonywania, takich jak przepływy skalarne i zmiennoprzecinkowe, błędy indeksu tablicowego, podział na zero i powiązane wyjątki arytmetyczne, niezainicjowane zmienne, wyścigi danych włączone wspólne struktury danych itp. Analizator był w stanie automatycznie wykryć błąd lotu Ariane 501. Analiza statyczna wbudowanego oprogramowania o krytycznym znaczeniu dla bezpieczeństwa (takiego jak oprogramowanie awioniczne) jest bardzo obiecująca .

Chciałbym dokładnie wyjaśnić wpływ tego pojedynczego zdarzenia na podejścia i narzędzia do testowania oprogramowania.

_{¹ 7 miliardów dolarów prawdopodobnie odnosi się do całkowitego kosztu projektu Ariane 5, Wikipedia donosi, że niepowodzenie spowodowało stratę ponad 370 milionów dolarów. Wciąż dość droga porażka, ale nie zbliżona do kwoty 7 miliardów dolarów.}

Technicznie rzecz biorąc, był to raczej przypadek „ zgnilizny oprogramowania ”. Oprogramowanie do sterowania lotem zostało przetworzone z wcześniejszej rakiety Ariane 4, co jest rozsądnym posunięciem, biorąc pod uwagę, jak drogie jest tworzenie oprogramowania, zwłaszcza gdy jest to oprogramowanie o kluczowym znaczeniu, które musi zostać przetestowane i zweryfikowane według znacznie bardziej rygorystycznych standardów niż większość oprogramowania komercyjnego.

Niestety, nikt nie zadał sobie trudu przetestowania, jaki wpływ miałaby zmiana środowiska operacyjnego, a gdyby tak się nie stało, nie przeprowadził testowania w wystarczająco dokładnym standardzie.

Oprogramowanie zostało zbudowane tak, aby oczekiwać, że pewne parametry nigdy nie przekroczą pewnych wartości (ciąg, przyspieszenie, zużycie paliwa, poziomy wibracji itp.). W normalnym locie na Ariane 4 nie stanowiło to problemu, ponieważ parametry te nigdy nie osiągnęłyby nieprawidłowych wartości bez czegoś już spektakularnie złego. Ariane 5 jest jednak znacznie potężniejszy, a zakresy, które wydają się głupie na 4, mogą dość łatwo wystąpić na 5.

Nie jestem pewien, jaki parametr wykroczył poza zakres (mogło to być przyspieszenie, muszę to sprawdzić), ale kiedy to zrobił, oprogramowanie nie było w stanie sobie poradzić i wystąpiło przepełnienie arytmetyczne, w przypadku którego wystąpiło zaimplementowano niewystarczające sprawdzenie błędów i kod odzyskiwania. Komputer sterujący zaczął wysyłać śmieci do przegubów dysz silnika, które z kolei zaczęły celować dyszą silnika dość losowo. Rakieta zaczęła się obracać i rozpadać, a automatyczny system samozniszczenia wykrył, że rakieta jest teraz w niebezpiecznej, niemożliwej do odzyskania pozycji i zakończył robotę.

Szczerze mówiąc, ten incydent prawdopodobnie nie nauczył żadnych nowych lekcji, ponieważ rodzaje problemów zostały wcześniej odkryte we wszystkich systemach, a istnieją już strategie radzenia sobie ze znajdowaniem i naprawianiem błędów. To, co zrobił ten incydent, zwróciło uwagę na to, że rozluźnienie w stosowaniu tych strategii może mieć ogromne konsekwencje, w tym przypadku miliony dolarów zniszczonego sprzętu, niektórych wkurzonych klientów i brzydkie podeptanie reputacji Arianespace.

Ten szczególny przypadek był szczególnie rażący, ponieważ skrót zastosowany w celu zaoszczędzenia pieniędzy ostatecznie kosztował ogromną kwotę, zarówno pod względem pieniędzy, jak i utraty reputacji. Gdyby oprogramowanie zostało przetestowane tak samo solidnie w symulowanym środowisku Ariane 5, jak wtedy, gdy zostało pierwotnie opracowane dla Ariane 4, błąd z pewnością ujawniłby się na długo przed zainstalowaniem oprogramowania w sprzęcie uruchamiającym i przekazaniem polecenia prawdziwy lot. Ponadto, jeśli twórca oprogramowania celowo wrzucił jakieś bzdury do oprogramowania, błąd mógł nawet zostać wychwycony w erze Ariane 4, ponieważ uwypukliłoby to fakt, że odzyskanie błędu, które miało miejsce, było nieodpowiednie.

Krótko mówiąc, tak naprawdę nie uczył nowych lekcji, ale zwrócił uwagę na niebezpieczeństwa wynikające z nie pamiętania starych. Wykazało również, że środowisko, w którym działa system oprogramowania, jest tak samo ważne, jak samo oprogramowanie. To, że oprogramowanie jest weryfikowalne pod kątem środowiska X, nie oznacza, że ​​nadaje się do zastosowania w podobnym, ale odrębnym środowisku Y. Wreszcie podkreśliło, jak ważne jest, aby oprogramowanie o znaczeniu krytycznym było wystarczająco solidne, aby poradzić sobie z okolicznościami, które nie powinny mieć miejsca stało się.

Porównaj lot 501 z Apollo 11 i jego problemami z komputerem. Podczas gdy oprogramowanie LGC uległo poważnej usterce podczas lądowania, zostało zaprojektowane tak, aby było wyjątkowo solidne i mogło pozostać w stanie operacyjnym pomimo uruchomionych alarmów programowych, nie narażając żadnych astronautów na niebezpieczeństwo i wciąż będąc w stanie wypełnić swoją misję.

Był to głównie problem ponownego użycia i problem z zarządzaniem, a nie kodowanie. Z moich wspomnień (prawdopodobnie źle się mylę) z raportu.

• jeden podsystem został zaprojektowany dla Ariane IV. Trajektorie Ariane IV nie mogły doprowadzić do przepełnienia, a następnie celowo zdecydowano, że jeśli wystąpi, będzie to problem ze sprzętem, a zamknięcie podsystemu i przejście na zapas jest właściwą rzeczą.

• w przypadku Ariane V postanowiono ponownie wykorzystać ten podsystem i nie sprawdzać założeń i kodu, ale polegać na testowaniu.

• ponadto postanowiono zrezygnować z pełnego testowania.

Różne parametry lotu Ariane V spowodowały przepełnienie. Zamknij główny. Zamknij zapasowy. Autodestrukcja.

Dodatkowe rzeczy, które pamiętam:

• podsystem w momencie przepełnienia przestał być użyteczny. Można argumentować, że jego awaria nie powinna była wywołać autodestrukcji. (Z drugiej strony dodatkowa złożoność sama w sobie może być źródłem problemów).

• do magistrali wysłano dane debugowania, kiedy nie powinno. Nie pamiętam tego konkretnego.

Jak wspomnieli inni, spowodowało to, że przemysł ogólnie ponownie przeanalizował koncepcję ponownego użycia i umieścił ją w szerszym układzie odniesienia, w którym komponenty nie są oceniane osobno, ale w kontekście całego systemu. To znacznie zmniejsza atrakcyjność ponownego użycia, ponieważ nawet jeśli element może być ponownie użyty bez zmian, nadal musi być analizowany przy użyciu nowego zestawu założeń. Inną konsekwencją jest to, że sprzęt do tworzenia kopii zapasowych z tym samym oprogramowaniem nie jest tak atrakcyjny, ponieważ większość nowoczesnego sprzętu jest o rząd wielkości bardziej niezawodna niż nowoczesne oprogramowanie. Słyszałem, że niektóre kontrakty na obronę wymagają dwóch oddzielnych systemów oprogramowania opracowanych przez różne zespoły wykorzystujące różne technologie działające na podstawie tej samej specyfikacji, aby zweryfikować prawidłowe wdrożenie.