737 MAX pokazał, że katastrofalny problem software’u może być poprawnym kodem realizującym błędne założenia systemowe
MCAS w pierwotnej konfiguracji Boeinga 737 MAX mógł automatycznie polecać ruch stabilizatora nose-down w określonych warunkach. System opierał swoje aktywowanie m.in. na danych z jednego aktywnego czujnika kąta natarcia, a w sekwencji zdarzeń związanych z katastrofami Lion Air 610 i Ethiopian Airlines 302 załogi mierzyły się z błędnymi wskazaniami i powtarzającymi się komendami. Raport JATR podkreślał problemy projektu, założeń dotyczących reakcji pilotów, certyfikacji i integracji funkcji. To nie jest historia „jednej złej linijki”, lecz przykład systemowego błędu bezpieczeństwa.
Kod może robić dokładnie to, co zapisano, i nadal być niebezpieczny
Nie każdy software failure jest bugiem implementacyjnym. Jeśli wymaganie brzmi „przy takim sygnale wykonaj taką korektę”, program może realizować je perfekcyjnie. Problem pojawia się, gdy wymaganie zakłada zbyt wiarygodny sensor albo zbyt optymistyczną reakcję człowieka.
MCAS zmieniał zachowanie stabilizatora
System został wprowadzony jako element charakterystyk pilotażowych MAX-a. W określonych warunkach automatycznie wydawał komendy nose-down. Pierwotna architektura systemu i sposób jego certyfikacji stały się przedmiotem intensywnych analiz po wypadkach.
Pojedynczy aktywny sensor tworzył słaby punkt
Raporty i późniejsze zmiany projektu wskazywały na problem zależności od jednego źródła angle-of-attack dla aktywacji MCAS. Redundancja fizyczna sensorów nie daje ochrony, jeśli funkcja w danym momencie ufa tylko jednemu bez wystarczającego cross-checku.
Założenia o reakcji pilotów były częścią safety case
JATR stwierdzał, że Boeing przyjął założenia dotyczące zdolności załogi do rozpoznania i reakcji na określone nieprawidłowości. Realne środowisko obu wypadków było bardziej złożone, z alarmami i dużym obciążeniem pracą. Human factors nie są więc dodatkiem do software’u; są częścią systemu sterowania.
Certyfikacja funkcji rozproszonej po systemie jest trudna
Zmiana software’u może pozornie wydawać się lokalna, ale wpływać na aerodynamikę, szkolenie, dokumentację i procedury awaryjne. JATR rekomendował bardziej zintegrowane podejście do oceny zmian oraz ich kumulatywnych skutków.
Nie wolno redukować katastrof do jednego komponentu
Katastrofy lotnicze mają łańcuch przyczyn i warunków. MCAS był kluczowym elementem analiz, ale dochodzenia obejmowały także sensory, maintenance, alerty, szkolenie, certyfikację i działania załóg. Edukacyjnie najważniejsze jest to, że software safety wymaga oceny całego systemu socio-technical, nie samej funkcji w kodzie. Redundancja sensorów ma sens dopiero wtedy, gdy system porównuje ich wyniki i ma strategię dla rozbieżności. Dwa czujniki zamontowane na samolocie nie tworzą automatycznie dwukanałowej decyzji, jeśli konkretna funkcja używa w danym momencie tylko jednego.
Safety case musi obejmować interakcję automatyki z człowiekiem
W lotnictwie system automatyczny nie działa w próżni. Jego błędy, alerty i komendy trafiają do załogi znajdującej się w dynamicznej sytuacji. Analiza nie może więc zakładać idealnego pilota reagującego na pojedynczy symptom w spokojnym kokpicie. Trzeba modelować jednoczesne alarmy, nieprawidłowe wskazania, wysiłek fizyczny, czas na diagnozę i znajomość funkcji wynikającą ze szkolenia. Human factors jest częścią architektury, bo decyzja projektowa może przenieść odpowiedzialność z automatu na człowieka w ciągu sekund. JATR zwracał uwagę na konieczność szerszej, zintegrowanej oceny funkcji MAX-a. To uniwersalna lekcja dla AI i automatyzacji: nie wystarczy, że system „może zostać wyłączony przez operatora”. Trzeba wykazać, że operator realnie rozpozna sytuację, zrozumie ją i zdąży przejąć kontrolę w najgorszym wiarygodnym scenariuszu. To podejście prowadzi do zasady system-theoretic safety: zagrożenie może powstać z interakcji kilku poprawnych komponentów, jeśli ich wspólne zachowanie nie zostało przeanalizowane. Test jednostkowy MCAS nie mógł więc zastąpić testu całej sytuacji pilotażowej. Weryfikacja powinna więc obejmować również scenariusze z fałszywym sensorem, wieloma jednoczesnymi alertami i opóźnioną reakcją załogi. To właśnie takie warunki sprawdzają, czy bezpieczeństwo istnieje poza nominalną ścieżką.