Poważny incydent spowodowany awarią brytyjskich krajowych służb ruchu lotniczego (Nats) w sierpniu 2023 r. może zdarzać się bardzo rzadko, ale w ostatecznym raporcie dotyczącym awarii systemu zalecono wprowadzenie 34 zmian.
W raporcie przygotowanym dla Urzędu Lotnictwa Cywilnego Wielkiej Brytanii (CAA) przez niezależny panel oceniający zbadano, co można zrobić lepiej, aby ograniczyć skutki awarii, która wystąpiła w wyniku przesłania do systemu planu lotu w niepoprawnym formacie.
W przypadku awarii systemu podstawowego, system zapasowy ma za zadanie bezproblemowo przejąć przetwarzanie. Autorzy ww Raport końcowy z dochodzenia w sprawie poważnego incydentu Nat zauważył, iż w tym przypadku system główny nie zawiódł, ale działał zgodnie z zaprogramowaniem. Przełączył się w tryb konserwacji, aby mieć pewność, iż niemożliwe do pogodzenia – a zatem potencjalnie niebezpieczne – informacje nie zostaną przesłane do kontrolera ruchu lotniczego.
Jednakże system zapasowy zastosował tę samą logikę do planu lotu z tym samym skutkiem. Następnie zgłosił swój własny krytyczny wyjątek, zapisując plik dziennika w dzienniku systemowym i przeszedł w tryb konserwacji.
Awaria Nats wystąpiła, ponieważ zarówno podstawowy, jak i zapasowy Zautomatyzowany pakiet odbioru planu lotu (FPRSA-R) znajdowały się w trybie konserwacji w celu ochrony bezpieczeństwa operacji kontroli ruchu lotniczego. Oznaczało to, iż plany lotu nie mogły być już automatycznie przetwarzane i interwencja ręczna było teraz wymagane.
W raporcie zalecono, aby Nats dokonali przeglądu obecnej struktury dowodzenia, wspierającej ją technologii i procesów. Powinno to przeanalizować, czy obecny model prawdopodobnie doprowadzi do najlepszych wyników w większości incydentów, czy też można go dalej optymalizować poprzez dodanie alternatywnych opcji.
Autorzy raportu zalecili, aby przegląd ten obejmował co najmniej opcje alternatywnych modeli i przykłady innych skutecznych struktur dowodzenia, w tym wykorzystanie pojedynczego modelu menedżera incydentów. Zauważyli również, iż takie opcje powinny obejmować wytyczne dotyczące tego, kiedy zastosowanie każdej opcji jest najwłaściwsze, i zasugerowali przegląd wymagań szkoleniowych w celu maksymalizacji zdolności w zakresie nadzoru operacyjnego podczas incydentów oraz wymagań systemowych i procesowych w celu wspierania wybranych struktur, w tym podejmowania decyzji, eskalacja i stworzenie wspólnego obrazu operacyjnego.
Kiedy Nats przeszedł w tryb offline, podzbiór nieprzetworzonych danych pozostał w systemie, ale znajdował się poza ustaloną kolejką pauzy. Wymagało to dalszej eskalacji w celu zidentyfikowania pierwotnej przyczyny problemu.
W raporcie zalecono dokonanie przeglądu dokumentacji kontroli ruchu lotniczego w celu zapewnienia lepszego zrozumienia złożoności i zachowania systemu przez inżynierów i użytkowników, którzy nie zajmują się systemem. Należy również przeprowadzić na wysokim szczeblu wspólny przegląd służb technicznych i operacyjnych kluczowych systemów krytycznych. W raporcie zalecono, aby przegląd ten potwierdził, iż dokumentacja operacyjna każdego poddanego przeglądowi systemu zawiera wystarczający opis i przejrzystość, aby umożliwić bezpieczną i niezawodną obsługę systemu w nieoczekiwanych okolicznościach.
Autorzy raportu, choć zachowali procedury eskalacyjne, wskazali, iż wcześniejszy kontakt z dostawcą najprawdopodobniej przyspieszyłby rozwiązanie zdarzenia.
Zalecili, aby Nats zaktualizowali proces eskalacji, aby zapewnić wytyczne dotyczące czasu lub innych kluczowych kryteriów, które powinny zostać uruchomione, kiedy i w jakich okolicznościach wymagane jest wsparcie dostawcy. „Nats powinien stworzyć jeden kontrolowany dokument zawierający szczegółowe informacje na temat umów z dostawcami i powiązanymi osobami kontaktowymi, które zapewniają całodobowe wsparcie” – stwierdzono w raporcie. „Te szczegóły powinny być dostępne dla wszystkich w Nats, który może być zobowiązany do wsparcia reakcji na incydent. Powinny one obejmować co najmniej poziomy wsparcia inżynieryjnego od 1 do 3.”
Wśród mniejszych zaleceń jest to, iż biorąc pod uwagę złożoność architektury systemu, która jest regularnie zmieniana i aktualizowana, niemożliwe jest utrzymanie aktualnego ogólnego mapowania systemu Nat. Autorzy raportu zalecili przeprowadzenie oceny wykonalności zastosowania nowej technologii lub procesu inżynieryjnego opartego na modelu w celu szybkiego dostarczenia zespołom wymaganych informacji o schemacie systemu na wczesnych etapach incydentu.
Powiedzieli również, iż dyrektor służb technicznych powinien dokonać przeglądu aktualna dokumentacja eksploatacyjna wspierające wdrażanie nowej technologii lub procesu inżynieryjnego opartego na modelu, który wspiera szybkie mapowanie. „Musi to zapewnić wystarczającą i dokładną szczegółowość różnych poziomów wsparcia inżynieryjnego, aby móc zobaczyć najważniejsze systemy interfejsów wysokiego poziomu i metody ich łączenia” – napisali.
Głównym celem tego przeglądu powinna być pomoc w identyfikacji problemów, które mogą występować przed lub za konkretnym systemem, w którym usterka pojawia się po raz pierwszy.
