Nieobliczalny software
Największe katastrofy oprogramowania
Szalejące tornado, tsunami i trzęsienie ziemi razem wzięte nie budzą takiej grozy, jaką sieje wadliwe oprogramowanie: eksplodujące rakiety, krachy na giełdach i – nieomalże – trzecia wojna światowa.
1962 - Mariner 1 - Zaraz po starcie rakieta zbacza z kursu i zostaje zniszczona. Powód: programista pominął w kodzie znak górnego podkreślenia („¯”). Przylądek Cape Canaveral na Florydzie. 22 czerwca 1962 roku punktualnie o godzinie 9:26 oficer do spraw bezpieczeństwa naciska czerwony guzik... i rakieta Mariner 1 zostaje zniszczona. Zamontowana na niej pierwsza w historii ludzkości sonda międzyplanetarna miała zbadać Wenus. Zamiast tego szczątki Marinera po 293 sekundach lotu spadły na Karaiby, rozpoczynając tym samym serię spektakularnych katastrof software’owych. Tydzień później eksperci NASA znaleźli przyczynę: programista zapomniał przenieść znaku „¯” z odręcznych notatek do aplikacji sterującej. Dodatkowy bajt kodu służył temu, aby komputer określał pozycję rakiety, bazując na jej uśrednionej prędkości. Znaku zabrakło, więc parametry były wyliczane na podstawie aktualnych danych, które często się zmieniały. Aby skompensować fluktuacje, procesor nieustannie wysyłał nowe polecenia sterujące, które sprawiały, że Mariner coraz bardziej zbaczał z zaplanowanego kursu. Po niecałych 5 minutach lotu zdecydowano się go zdetonować, aby uniknąć większego nieszczęścia. Nauka płynąca z tej katastrofy przybrała później w NASA postać wewnętrznej notatki: „No detail is too small to overlook” – żaden szczegół nie jest zbyt mały, aby go przeoczyć. Kosmos: Rozbicie na skutek błęduPonad 30 lat później, 4 kwietnia 1996 roku o godzinie 9:34, na kosmodromie w Kourou pracownik kontroli lotów znów naciska czerwony guzik, niszcząc tym razem Ariane 5. Powód? Rakieta po 37 sekundach dziewiczego lotu zboczyła z kursu, grożąc runięciem na tereny zamieszkane. Również jej szczątki spadły na Karaiby. Analogie z Marinerem są nie tylko powierzchowne: jak ustaliła speckomisja europejskiej agencji kosmicznej ESA, powód katastrofy leżał w przeciążonym systemie nawigacyjnym SRI, który inżynierowie przenieśli bez adaptacji z poprzednika rakiety, Ariane 4. Przyczynę tej decyzji podano w oficjalnym raporcie: „Panowało przekonanie, że nie byłoby wskazane dokonywanie zmian w softwarze, który tak dobrze funkcjonował w Ariane 4”. Jest to postawa w języku angielskim określana jako: Never touch a running system. Sęk w tym, że Ariane 5 była nie tylko większa, ale również przyspieszała pięć razy szybciej. SRI musiał więc radzić sobie z wartościami, które nie występowały w przypadku Ariane 4. I tu pojawił się problem: 16-bitowy moduł nie mógł konwertować prędkości wznoszenia się rakiety do wartości całkowitej, ponieważ zapisywano ją w formacie 64-bitowej liczby zmiennoprzecinkowej, a ta na 16 bitach po prostu się nie mieści. Skutek: przepełnienie pamięci, które powodowało nadpisywanie innych zmiennych sytemu. W przypadku poważnego SRI powinien zatrzymać obliczenia i przesyłać na komputer pokładowy Ariane jedynie wartości zmiennych. Jednak ten w dalszym ciągu interpretował odbierane informacje jako dane nawigacyjne. A te mówiły mu, że rakieta ciągle schodzi z kursu. Nanosił więc fatalne poprawki, które doprowadziły do rozbicia rakiety. Zimna wojna: Maszyny w natarciuKatastrofy kosmiczne są spektakularne, ale prawdziwymi horrorami okazały się awarie software’owe podczas zimnej wojny. Obydwa mocarstwa polegały wtedy na analizach tworzonych przez komputery i oczywiście były narażone na ich błędy. W 1979 roku amerykański system obronny NORAD zameldował o 2020 atakujących rosyjskich rakietach. Jednak scenariusz był do tego stopnia nieprawdopodobny, że wojskowi natychmiast pomyśleli o błędzie komputera. I tak było w rzeczywistości: procesor NORAD-a na skutek defektu sprzętowego szmuglował w przesyłanych danych przypadkowe bity. Dzięki dodatkowej kontroli błędne wiadomości były odfiltrowywane – aż do ostrzeżenia o ataku rakietowym. Niemalże do unicestwienia ludzkości doprowadził meldunek rosyjskiego systemu satelitarnego. 26 września 1983 roku pół godziny po północy komputer pokazał start pięciu amerykańskich rakiet międzykontynentalnych. Znajdujący się w leżącym około 50 km od Moskwy bunkrze „Serpuchow 15” podpułkownik Stanisław Petrow musiał zadecydować, czy ZSRR faktycznie zostało zaatakowane. Jego meldunek stanowiłby podstawę dla sztabu generalnego, aby wydać rozkaz przeciwuderzenia atomowego. Petrow założył, że to fałszywy alarm: „Miałem takie komiczne uczucie w brzuchu. A poza tym nikt nie zaczyna wojny nuklearnej za pomocą pięciu rakiet”. Błąd znaleziono jeszcze tego samego dnia: satelita zinterpretował odbicia słoneczne na chmurach nad bazą amerykańskich sił powietrznych w Montanie jako start rakiet. Ale niedowierzanie alarmom komputerowym, jeśli są nieprawdopodobne, może również prowadzić do poważnych błędów, co najlepiej pokazuje odkrycie dziury ozonowej. Na jej trop wpadł brytyjski naukowiec Joe Farman, badając glebę w stacji antarktycznej Halley Bay. W maju 1985 roku opublikował wyniki badań w specjalistycznym czasopiśmie „Nature”. NASA namierzyła dziurę ozonową już siedem lat wcześniej za pomocą satelitów Nimbus 7. Tylko że wtedy nikt się o tym nie dowiedział. Zamontowane na satelitach sensory TOMS dostarczały 140 000 wartości dziennie, ale software analizujący NASA został tak zaprogramowany, że pomiary zbyt odbiegające od normy 180 Dobson Units (DU) były oznaczane jako „niepewne” i usuwane. Powstałe w ten sposób dziury w strumieniu danych aplikacja wypełniała wartościami bardziej prawdopodobnymi. Pierwotne wartości pomiarowe drzemały w tym czasie w banku danych do czasu pojawienia się artykułu Farmana. Krótko po tym istnienie dziury ozonowej mogła potwierdzić też NASA – po prostu sięgnęła po „błędy pomiaru” z przeszłości. Dysponując prawidłowo napisanym software’em, mogłaby to uczynić dużo wcześniej. Megaprojekty: Wylęgarnia awariiW porównaniu z tymi, do których doszło w wieku XX, katastrofy software’owe ostatnich lat nie były aż tak groźne. Z powodu awarii wielkie projekty, które poniosły klęskę, trafiły wprawdzie na pierwsze strony gazet, ale nie zagroziły ludzkiemu życiu. W przypadku Airbus A380 koncern EADS miał przynajmniej wybór. A to dlatego, że kable były za krótkie. Największy samolot pasażerski świata został w całości zaprojektowany komputerowo. W Hamburgu powstawała elektronika wraz z okablowaniem, a w Tuluzie kadłub. Gdy latem 2004 technicy zaczęli łączyć elementy elektroniczne za pomocą bez mała 530 kilometrów przewodów (na każdy samolot), okazało się, że w przypadku wielu z nich to się nie uda – kable były za krótkie. Efekt? Koszty się podniosły, a terminy odbioru przesuwały. Rozpoczęta przez jednego z ówczesnych szefów Airbusa, Christiana Streiffa, analiza ujawniła źródło kłopotów z kablami: inżynierowie używali różnych wersji programu CAD CATIA, które nie były ze sobą kompatybilne – edycja 4 w Hamburgu, a 5 w Tuluzie. Zamieszanie z numerami wersji wydaje się małe. Jednak w rzeczywistości chodzi tu o ogromne różnice jakościowe. Wersję 4 zaprogramowano w Fortranie i przeznaczono do systemu Unix. Wersja 5 została napisana całkowicie na nowo w C++ i można ją było zainstalować tylko w Windows. Różnice dotyczyły więc wręcz niekompatybilnych formatów plików. W efekcie dane nie dawały się bezstratnie konwertować, a metadane – takie jak adnotacje inżynierów do określonych części składowych – przepadały. Airbus miał wprawdzie własne oprogramowanie konwertujące, ale nie funkcjonowało ono prawidłowo Właściwy problem leżał według Streiffa na wyższych piętrach koroporacji: „Chodzi o nieprawidłowe działanie kierownictwa, które nie zatroszczyło się wystarczająco o kooperację wewnątrz projektu”. Szef sprzedaży Airbusa John Leahy podaje więcej szczegółów: „Odpowiedzialni ludzie nie zwracali po prostu uwagi na ten problem. Zaniechali przeszkolenia inżynierów na CATIA 5. Nie złagodzili też w Hamburgu niechęci wobec nowej wersji tego programu”. Skutek: dodatkowe koszty w wysokości 5 miliardów euro. |
Kup najtaniej
http://www.youtube.com/watch?v=_ZCp5h1gK2Q