Tragiczna w skutkach automatyzacja: MCAS i 737 MAX

Jak zautomatyzowana funkcja bezpieczeństwa stała się częścią katastrofy

Kiedy dwa samoloty Boeing 737 MAX rozbiły się w odstępie zaledwie kilku miesięcy na przełomie 2018 i 2019 roku, śledczy znaleźli wspólny mianownik w oprogramowaniu sterującym lotem. System zaprojektowany, aby pomóc maszynie radzić sobie z silnikami o innym kształcie — Maneuvering Characteristics Augmentation System, czyli MCAS — został zmodyfikowany na późnym etapie prac projektowych w sposób, który uczynił jego działanie bardziej agresywnym i, co kluczowe, uzależnionym od pojedynczego czujnika kąta natarcia. Zmiany te usunęły warstwy ochronne i naraziły załogi na szybki, dezorientujący tryb awaryjny, do którego rozpoznania ani przeciwdziałania piloci nie zostali przeszkoleni.

MCAS: co system miał robić w założeniu

MCAS został wprowadzony, aby MAX prowadził się tak, jak wcześniejsze modele 737, po tym jak większe i zamontowane bardziej z przodu silniki zmieniły aerodynamikę samolotu. Jego nominalne zadanie było skromne: gdy określone warunki sugerowały, że nos maszyny może zbyt mocno się zadrzeć, MCAS lekko przestawiał statecznik poziomy (trymował go) w dół, aby zachować spójność pilotażu. W pierwotnym zamyśle system miał działać subtelnie i rzadko.

Jak zmienił się system — i dlaczego miało to znaczenie

W trakcie prac rozwojowych Boeing rozszerzył rolę MCAS. Wdrożona wersja mogła aktywować się częściej i wywoływać większe wychylenia statecznika niż we wcześniejszych projektach, a ponadto została skonfigurowana tak, by reagować na dane z pojedynczego czujnika kąta natarcia, zamiast przeprowadzać weryfikację krzyżową z wielu źródeł. W przypadku katastrof lotów Lion Air i Ethiopian Airlines błędne dane o kącie natarcia wywołały powtarzające się sygnały pochylenia nosa w dół, z którymi piloci walczyli, ale których nie zdołali w porę przezwyciężyć. Przejście od konserwatywnego, nadmiarowego projektu do bardziej agresywnej implementacji opartej na jednym czujniku było decydującym czynnikiem tych awarii.

Dlaczego nazywanie MCAS „sztuczną inteligencją” wprowadza w błąd — i dlaczego to określenie wciąż ma znaczenie

W mediach i debacie publicznej katastrofy te bywają czasem określane jako porażka „sztucznej inteligencji”. Ten skrót myślowy jest kuszący, ale nieprecyzyjny. MCAS nie był modelem uczenia maszynowego, który sam trenował się na danych; była to deterministyczna logika sterowania lotem: zasady zakodowane tak, by reagować na konkretne dane wejściowe z czujników. Niebezpieczeństwo jest jednak to samo, którego ludzie obawiają się w przypadku nieprzejrzystych systemów AI — zautomatyzowane zachowanie ukryte przed użytkownikami końcowymi i organami regulacyjnymi, wchodzące w interakcję z nieprzewidywalnymi sygnałami ze świata rzeczywistego w sposób, którego projektanci w pełni nie przewidzieli.

Etykietowanie MCAS jedynie jako „automatyzacji” może umniejszać znaczenie wyborów projektowych — zwłaszcza tych dotyczących przejrzystości, redundancji i interakcji człowiek-maszyna — które zmieniły funkcję ochronną w zagrożenie. Przypadek tych lotów pokazuje, że nawet algorytmy nieuczące się wymagają rygorystycznej inżynierii bezpieczeństwa, tego samego rodzaju identyfikowalnych wymagań i niezależnych testów, których obecnie oczekujemy od systemów AI w innych dziedzinach.

Błędy organizacyjne i regulacyjne spotęgowały wady techniczne

Wybory techniczne nie dokonywały się w próżni. Liczne kontrole i przesłuchania wykazały, że problemy z nadzorem, komunikacją i kulturą korporacyjną zwiększyły ryzyko. Organom regulacyjnym nie zawsze przedstawiano pełne szczegóły ewolucji MCAS; instrukcje dla pilotów początkowo pomijały tę funkcję, a założenia, że MCAS będzie aktywować się rzadko, ograniczyły szkolenie pilotów w zakresie reagowania na jego działanie. Te instytucjonalne awarie zmieniły błąd inżynieryjny w kryzys bezpieczeństwa publicznego.

Poprawki wprowadzone przez Boeinga i organy regulacyjne

Po uziemieniu floty MAX-ów, Boeing i władze lotnicze wymusiły zmiany w oprogramowaniu i procedurach operacyjnych. Zmieniony projekt ogranicza MCAS tak, że działa on tylko wtedy, gdy oba czujniki kąta natarcia podają zgodne dane, ogranicza go do jednej aktywacji na zdarzenie i łagodzi siłę sygnałów trymowania. Organy regulacyjne zaostrzyły również wymagania dotyczące dokumentacji, szkolenia pilotów i niezależnej weryfikacji, zanim typ ten został dopuszczony do powrotu do eksploatacji. Zmiany te wyeliminowały bezpośrednie tryby awaryjne, ale nie wymazują szerszych pytań o ład korporacyjny, które ujawnił kryzys.

Lekcje dla szerszej debaty o AI i automatyzacji

Historia MAX-a to ostrzegawczy elementarz dla każdego, kto wdraża automatyzację na dużą skalę. Wyróżniają się cztery lekcje:

Są to dobrze znane hasła w kręgach etyki i bezpieczeństwa AI, ale 737 MAX pokazuje, że nie są one abstrakcyjne. W systemach krytycznych dla bezpieczeństwa koszty pomyłki są natychmiastowe i ostateczne.

W jakim kierunku powinna zmierzać dalsza dyskusja

Poprawki techniczne pozwoliły na powrót MAX-a do służby pod ścisłymi warunkami, ale ten incydent pozostaje punktem odniesienia dla tego, jak nie zarządzać automatyzacją w branżach regulowanych. Dla decydentów i inżynierów koniecznością jest przełożenie tych lekcji na możliwe do wyegzekwowania standardy: jaśniejsze ścieżki certyfikacji dla systemów zautomatyzowanego podejmowania decyzji, obowiązkowe zgłaszanie istotnych zmian projektowych oraz struktury instytucjonalne redukujące konflikty interesów między producentami a certyfikatorami.

Dla dziennikarzy i opinii publicznej jest to również przypomnienie o potrzebie precyzji w nazewnictwie. „AI” przyciąga nagłówki, ale podstawowym problemem w przypadku MAX-a nie była sztuczna inteligencja w sensie uczenia maszynowego — była to kombinacja agresywnej automatyzacji, słabej przejrzystości i osłabionych praktyk bezpieczeństwa. Potraktowanie tej kombinacji jako wyzwania inżynieryjnego i zarządczego daje nam skuteczniejszą drogę do zapobieżenia powtórce.

Podsumowanie

Katastrofy 737 MAX nie były nieuniknione. Były one wynikiem konkretnych decyzji projektowych, niesprawdzonych założeń i awarii instytucjonalnych. W miarę jak automatyzacja i AI wkraczają w kolejne dziedziny, przypadek MAX-a powinien służyć jako dobitny przykład: bezpieczniejsze systemy powstają nie z wiary w fragment kodu, lecz z konserwatywnego projektowania, jasnej komunikacji z użytkownikami, niezależnego przeglądu i solidnego nadzoru regulacyjnego. Nie są to techniczne niuanse — to warunki wstępne bezpieczeństwa publicznego.