Katastrofa lotu Malaysia Air 17 przypomniała wielu o podobnym incydencie który miał miejsce nad Zatoką Perską 3 lipca 1988 roku, gdy samolot Iran Air Flight 655 został zestrzelony przez krążownik rakietowy USS Vincennes (CG-49). Wszystkie 290 osób na pokładzie samolotu zginęło (w przypadku MA17 zginęło 298 osób, pasażerowie wraz załogą).
W tamtym czasie katastrofa spotkała się ze zdziwieniem. Vincennes był wyposażony w nowy wówczas system walki Aegis, najbardziej zaawansowany system obrony powietrznej na świecie. Napędzany najnowocześniejszą technologią komputerową, Aegis został zaprojektowany do identyfikowania, śledzenia i zestrzeliwania setek radzieckich bombowców jednocześnie. Jak więc system ten mógł popełnić tak poważny błąd w starciu z pojedynczym cywilnym samolotem pasażerskim?
Oficjalny raport Marynarki Wojennej Stanów Zjednoczonych całkowicie oczyścił firmę Aegis z zarzutów, obwiniając o incydent załogę okrętu. Dużo później pojawiły się szczegóły dotyczące działania systemu Aegis, które zdecydowanie sugerują, że do zestrzelenia doszło przynajmniej częściowo z powodu krytycznych błędów w interfejsach użytkownika systemu Aegis.
Jeśli nie jesteś zaznajomiony z tym incydentem, Wikipedia ma stronę na ten temat, która daje dobry wgląd (https://en.m.wikipedia.org/wiki/Iran_Air_Flight_655). Zamiast podsumowywać cały incydent, chciałbym skupić się na problemach z interfejsem użytkownika, które doprowadziły kapitana i załogę Vincennes do popełnienia tak tragicznego błędu.
Pierwszy błąd interfejsu użytkownika, który przyczynił się do katastrofalnego zestrzelenia samolotu Iran Air Flight 655, miał miejsce wkrótce po starcie samolotu z międzynarodowego lotniska Bandar Abbas w Iranie.
Tak wtedy, jak i teraz, każdy duży samolot na świecie jest wyposażony w urządzenie zwane IFF - "identyfikacja przyjaciela lub wroga". Jest to transponder radiowy, który odpowiada na żądania za pomocą zestawu kodów opisujących, czy samolot jest cywilny czy wojskowy oraz jakiego rodzaju jest to samolot.
Lot 655 był wyposażony w IFF i prawidłowo zgłosił, że był to cywilny samolot pasażerski. Krótko po starcie Vincennes odpytał IFF samolotu i otrzymał potwierdzenie, że był to cywilny samolot pasażerski. Jak na razie wszystko w porządku.
Problem pojawił się w sposobie działania konsoli IFF systemu Aegis. Operatorzy "podłączali" nowe kontakty do Aegis w celu śledzenia, używając kontrolera do przesuwania kursora nad kontaktem, a następnie naciskając przycisk. Po "podłączeniu" kontakt był śledzony przez Aegis. Ale co najważniejsze, jeśli operator nie wykonał dodatkowego kroku polegającego na "przyporządkowaniu" kursora do tego kontaktu, gdy kontakt się oddalał, kursor nie podążał za nim. Będzie kontynuował pingowanie żądań IFF w miejscu, w którym kontakt _był_, dopóki operator nie przesunie kursora ponownie.
W przypadku lotu 655 operator prawidłowo go podłączył, ale nie ustawił kursora, aby za nim podążał. Gdy lot 655 oddalił się, Vincennes nadal wysyłał żądania IFF na pas startowy, z którego wcześniej wystartował.
Następnym samolotem startującym z tego pasa był irański myśliwiec wojskowy F-14. Kursor pozostał na pasie startowym tylko przez około 90 sekund, ale było to wystarczająco długo, aby Vincennes otrzymał odpowiedź IFF odpowiadającą myśliwcowi wojskowemu. Tak więc lot 655 został przeklasyfikowany z nieznanego kontaktu na potencjalnie wrogi.
Kiedy kapitan i załoga Vincennes spojrzeli na swoje wyświetlacze, od tego momentu widzieli ten kontakt zmierzający w ich kierunku, oznaczony jako myśliwiec F-14.
Kolejny problem wynikał ze sposobu, w jaki Aegis przekazywał dane załodze.
Cały system został zaprojektowany wokół ekranów. Poszczególni członkowie załogi mieli własne ekrany do zarządzania danymi, za które byli odpowiedzialni. Konsole tych członków załogi przekazywały następnie dane do zestawu dużych wyświetlaczy, których kapitan i starsi oficerowie używali do śledzenia ogólnego obrazu sytuacji.
To samo w sobie nie było problematyczne. Ale co najważniejsze, gdy projektujesz duży widok "pulpitu nawigacyjnego" dla decydentów wyższego szczebla, jego sukces lub porażka będzie zależeć całkowicie od danych, które dostarczysz w tym widoku. Projektowanie dowolnego dashboardu wymaga selekcjonowania i podsumowywania informacji. Jeśli po prostu przekażesz wszystko, przytłoczysz ludzi, którym próbujesz pomóc. Pojawia się więc pytanie, co uwzględnić, a czego nie?
W przypadku oryginalnej wersji Aegis, duże wyświetlacze pokazywały pozycję i kierunek wszystkich śledzonych kontaktów - ale nie pokazywały wysokości. Ma to krytyczne znaczenie, ponieważ wysokość, a dokładniej _zmiana_ wysokości, dostarcza wskazówek co do zamiarów śledzonego kontaktu. Jeśli samolot zmierza w twoją stronę, ale się wznosi, szanse na to, że zamierza cię zaatakować, są niewielkie. Jeśli jednak nurkuje w twoim kierunku, jest to klasyczny profil ataku.
Gdy kapitan Vincennes patrzył, jak ten kontakt kieruje się w jego stronę, nie mógł na pierwszy rzut oka stwierdzić, czy nurkuje, czy się wspina. Informacje te były dostępne, ale tylko na małych ekranach poszczególnych operatorów, a nie na dużych wyświetlaczach. Utrudniało mu to prawidłową ocenę jego zamiarów.
Gdy lot 655 zbliżył się, kapitan Vincennes zdał sobie sprawę, że musi wiedzieć, czy samolot się wznosi, czy nurkuje. Poprosił więc o tę informację, co doprowadziło do trzeciej i ostatniej "awarii" UI.
Jedną z cech charakterystycznych systemu Aegis było to, że zapewniał on ujednolicony widok danych z czujników na wielu okrętach. Wszystkie statki w danej grupie zadań były połączone łączem danych. Jeśli wiele statków zahaczyło ten sam kontakt, Aegis automatycznie sortował raporty i łączył je w jeden śledzony kontakt widoczny dla operatorów na wszystkich połączonych statkach.
Aby ułatwić identyfikację śledzonych kontaktów, Aegis przypisywał każdemu nowemu czterocyfrowy numer śledzenia. Gdy wiele statków śledziło ten sam kontakt, ich lokalne systemy przypisywały mu różne numery śledzenia. Następnie Aegis sortował wiele kontaktów, wybierał jeden numer śledzenia jako oficjalny i odrzucał pozostałe numery śledzenia.
Istniały jednak dwa problemy z działaniem interfejsu użytkownika. Po pierwsze, odrzucone numery śledzenia były poddawane recyklingowi: były wrzucane z powrotem do systemu, dostępne do przypisania do nowych kontaktów. Po drugie, gdy numer śledzenia kontaktu został zmieniony przez Aegis, nie było oczywistego ostrzeżenia, że tak się stało. Numer po prostu zmieniał się na ekranach.
Kiedy lot 655 wystartował, został zaczepiony zarówno przez Vincennes, jak i jej eskortę, niszczyciel USS Sides. Vincennes przypisał jej numer śledzenia 4474; Sides przypisał jej numer 4131. Aegis ujednolicił kontakty pod numerem 4131. Numer 4474 był wtedy dostępny do ponownego użycia, więc Aegis przypisał go amerykańskiemu bombowcowi A-6, który akurat zniżał lot.
Chwilę przed podjęciem decyzji o oddaniu strzału, kapitan Vincennes poprosił o raport wysokości samolotu. Nie zdawał sobie jednak sprawy, że numer śledzenia uległ zmianie. Myślał, że nadal jest to numer 4474, numer, który pierwotnie przypisał mu jego statek. Poprosił więc o raport na temat 4474, a członek załogi, którego poprosił, sumiennie wprowadził 4-4-7-4 do swojej konsoli. Co powiedziało mu, że kontakt szybko się zmniejsza.
Lot 655 w rzeczywistości nie zniżał się. Wznosił się od momentu opuszczenia Bandar Abbas. Ale w kluczowym momencie operatorzy Aegis patrzyli na zupełnie inny samolot. Wtedy kapitan Vincennes wydał rozkaz do strzału, reszta jest historią.
Nie mam zamiaru zrzucać całej winy za zestrzelenie na Aegis. Jeśli przeczytasz stronę Wikipedii, zobaczysz, że tamtego ranka wiele rzeczy poszło nie tak. Ale Aegis też nie wydaje się bez winy. Zły projekt interfejsu spowodował, że załoga Vincennes źle zrozumiała sytuację, na którą patrzyli.
Raport Marynarki Wojennej obwinia załogę za niewłaściwe korzystanie z systemu, ale jeśli projektujesz systemy informatyczne, wiesz, że to wymówka. Ludzie pod wpływem stresu popełniają błędy, a nie ma bardziej stresującej sytuacji niż walka. Jeśli twój system nie jest na to odporny - jeśli nie robi wszystkiego, co w jego mocy, aby wspierać operatora, aby upewnić się, że otrzyma potrzebne informacje, nawet jeśli zgubi piłkę - wina nie leży po stronie operatora. Jest twoja.
PS: Jeśli naprawdę chcesz zagłębić się w temat, najlepsze, najbardziej przejrzyste i kompleksowe sprawozdanie, jakie znalazłem, znajduje się w pracy magisterskiej kapitana Sił Powietrznych USA Kristen Ann Dotterway z 1992 r. "Systematyczna analiza złożonych systemów dynamicznych: The Case of the USS Vincennes".
Kapitan Dotterway przedstawia wydarzenia minuta po minucie, konfrontuje szczegóły oficjalnej relacji Marynarki Wojennej z tymi przedstawionymi przez kapitana Vincennesa w kolejnych wywiadach i przedstawia dane pokazujące luki w relacji Marynarki Wojennej.
Jest to gruby dokument, ale jeśli chcesz naprawdę zagłębić się w ten temat, zajmie ci to znacznie więcej niż strona Wikipedii. Oto link, pod którym można pobrać plik PDF: https://apps.dtic.mil/sti/tr/pdf/ADA260260.pdf
Wpis ukradziony z https://octodon.social/@jalefkowit/111490485825183949