技術背景簡介
飛機之所以能在空中飛行，是因為機翼在不斷“攻擊”前方的空氣。顧名思義，攻角（Angle of Attack，AOA）就是指機翼絃線（如圖1所示的紅色長線）與相對風向（圖1中的藍箭頭）之間的夾角。在一定的範圍內，攻角越大，氣流對機翼“推動”作用向上的分量也就越大，從而飛機的升力越大。但是，如果攻角過大，升力就會急劇下降，從而發生失速。這個達到最大升力但即將失速的攻角稱為臨界攻角，一般是十幾到二十幾度。
圖1：攻角（Angle of Attack）的定義（來源：維基百科）。
飛機的攻角一般是通過機頭的上下俯仰（pitch）來調整。我們常見的客機尾部有一對水平方向的翼面，叫做水平尾翼。兩個水平尾翼的後邊緣各有一個能夠上下活動的舵面，叫做升降舵（elevator）。飛行員向後“拉桿”時，升降舵會向上偏轉，氣流對它有個向下壓的力，飛機就會抬頭；反之，飛行員向前“推杆”時，飛機就會低頭。但是，如果只有升降舵，飛行員即使在勻速平飛的時候，也得不停地推杆拉桿，這太累了。因此，為了提高俯仰方向上的靜穩定性，水平尾翼的水平翼面也是能夠旋轉的，稱為水平安定面（stabilizer）。把水平安定面調整到飛機力矩平衡的狀態，就叫做配平（trim）。配平大致可以分為人工、電動、自動配平三種方式。如圖2所示，人工配平就是用手去通過液壓傳動機構轉動安定面；電動配平是按動電鈕，向上或向下按一次，水平安定面就會轉動一點；自動配平則是讓計算機根據速度或自動駕駛系統的指令來操作。
圖2：波音737 MAX 8的俯仰控制系統（來源：[1]）。
前面我們提到，飛機攻角過大會導致失速。由於波音737 MAX 8氣動構型設計的一些原因，為防止失速，飛機安裝了MCAS系統，也就是在飛機的攻角感測器檢測到攻角超過臨界攻角時，自動轉動水平安定面，下壓機頭。不管自動駕駛開啟還是關閉，只要水平安定面的電源開著，MCAS系統就會起作用，而且不達目的不罷休，這點我們後面還會討論到。現在我們就來分析導致空難的三個環環相扣的技術問題。
問題一：攻角感測器讀數離譜並且不一致
波音737 MAX 8飛機有左右兩個獨立的攻角感測器。從埃航空難班機飛行記錄儀的資料（圖3）可以看出，右側攻角感測器（AOA-R）在15度左右比較正常，而左側攻角感測器（AOA-L）在05:38:45突然上升到75度左右了。此時飛機正在上升高度，攻角加上飛機本身的仰角就接近90度了，這意味著飛機幾乎是在豎直向上飛。這是當火箭呢？因此攻角感測器的數值顯然是離譜的。左右攻角感測器的差值也高達60度，側風的影響也不至於這麼大。然而MCAS系統並沒有考慮到這些，而是根據左側攻角感測器單方面的數值來下壓機頭。
計算機系統中有個著名的拜占庭將軍問題，就是幾個軍官之間在通訊不可靠、軍官中還可能有叛徒的情況下，如何保證忠誠的軍官之間能達成一致的協議。這個問題是早在20世紀七八十年代，Leslie Lamport就在NASA的容錯航電計算機系統專案中提出的。這也是使他獲得圖靈獎的重要成就之一。航空航天領域對容錯性要求很高，這些容錯的系統設計也在21世紀的今天被應用在上千上萬臺機器組成的資料中心裡。然而MCAS系統卻沒有足夠的容錯性。最早一些人把事故歸因於攻角感測器被鳥擊，但單側攻角感測器損壞就導致飛機失控，顯然不符合飛控系統的容錯性要求。在波音事故後的軟體更新 [3] 中，飛控系統將比較攻角感測器的輸入，如果相差超過5.5度就不會觸發MCAS系統，這就解決了第一個問題。
圖3：埃航空難班機飛行記錄儀的資料（來源：[1]）
問題二：MCAS的操作對飛行員不可見
去年的獅航空難前，飛行員操作手冊中根本沒有關於MCAS系統的說明，飛行員不知道為什麼機頭自己下沉了，此時飛行員的內心想必是蒙圈的。後來波音儘管更新了安定面失控檢查單，但MCAS在發現攻角達到臨界時還是不會通知飛行員，而是悄悄地執行安定面配平操作。此外，這個機型上的攻角指示器是選配的，因此事故航班的飛行員看不到攻角，也不知道攻角不一致，直到墜毀前幾十秒才發現左側攻角感測器（left alpha vane）故障這個根本原因（圖4），但由於後面將討論到的問題還是沒能挽救飛機。對有經驗的飛行員而言，攻角指示器確實不必要，不過有感測無指示，就很難發現儀表故障。很多自動系統為了讓使用者省心，隱藏了大量技術細節，卻給故障的定位和除錯帶來了麻煩。理想的設計應當是平時減少對使用者的干擾，但在異常時提醒使用者，使用者也能按需檢視系統的資料來源和內部細節。
圖4：埃航事故班機飛行歷史的最後階段（來源：[1]）
波音軟體更新中，增加了攻角指示器和攻角不一致的告警，如圖5所示。
圖5：波音軟體更新中飛行員主顯示皮膚上的攻角指示器和攻角不一致警告（來源：[3]）
問題三：MCAS系統與飛行員持續較勁
第三個問題就是MCAS系統把自己當成了救世主，不恢復攻角不罷休，不斷跟飛行員較勁，而且“力氣”比人更大。例如在去年獅航事故中，左右攻角感測器差了20度，飛行員與MCAS大戰二十多個回合，看起來膽戰心驚。如圖5所示，鋸齒狀的藍線是手動配平（trim manual），橙線是自動配平（trim automatic），每次手動配平之後自動配平都會被觸發，然後飛行員再去手動配平，但最後幾次自動配平的“力氣”明顯比人大，飛行員也無力迴天。海恩法則指出：每一起嚴重事故的背後，必然有29次輕微事故和300起未遂先兆以及1000起事故隱患。就在獅航事故班機的上一次飛行中，如圖6所示，就出現了飛行員與MCAS系統較勁的問題，還好控制住了，緊急返航成功。
圖6：獅航事故當次航班的飛行記錄儀資訊（來源：[2]）
圖7：獅航事故上一次航班的飛行記錄儀資訊（來源：[2]）
波音最近的軟體更新中，增加了兩個限制：首先，每次檢測到攻角異常，都只會啟動MCAS一次，而不是多次啟動MCAS直到攻角恢復正常。只要不是飛行員故意跟它較勁，只需修正一次安定面，就能從失速邊緣解除危險。其次，MCAS對安定面的輸入不能超過飛行員用力拉桿時對升降舵的輸入，這保證飛行員始終能通過拉桿的方式抵消MCAS的錯誤操作。多數情況下，AI系統不需要預防人類的惡意操作，而應當作為人類的輔助和失誤時的臨時補救。
問題四：要麼斷電，要麼開啟MCAS
最後一個問題是MCAS系統與電動控制系統的緊密耦合。埃航空難中，飛行員按照波音的檢查單，給水平安定面斷電（stab trim cutout）。我們知道，拉桿（升降舵）和配平（水平安定面）都可以控制飛機的俯仰。因此，在安定面狀態異常的情況下，飛行員用力拉了兩分多鐘的杆，讓飛機爬升。但是水平安定面一直這樣異常著總不是好事，因此飛行員還是想配平。在飛機超速的情況下，手動配平需要的力氣很大，飛行員弄不動。因此，飛行員又恢復供電，試圖電動配平。這在五秒後啟用了MCAS系統，一個俯衝把機頭拉到40度了（圖8）。在開啟電動系統的情況下，儘管自動駕駛系統可以關閉，但MCAS系統無法關閉。波音在獅航空難後給出的檢查單認為拔掉電源手動配平就行了，但在埃航的情況下手動弄不動。因此自動控制系統應該有辦法與基本電動系統解耦。此外，MCAS系統的操作幅度過大也是問題，最後的下壓機頭操作飛行員來不及挽回，這在波音的軟體更新中已經解決。
圖8：埃航事故班機拉桿、超速、嘗試手動配平失敗的過程（來源：[1]）
對AI系統的啟示
MCAS系統是有用的，但不容錯、不可見、不受限、難關閉的軟體設計導致了人機大戰，並以人類的慘敗告終。隨著物聯網、自動駕駛、工業自動化和工業網際網路的普及，越來越多重要甚至生命攸關的系統將使用人工智慧（AI）自動控制。在資料中心的自動控制系統中，也存在很多故障恢復機制反而導致了更大規模故障的案例 [4]。
我們希望AI系統能夠吸取四條教訓：
1.應當更謹慎地對待它的輸入，輸入異常時應提醒使用者並保護性關閉；
2.使用者應當知道AI的存在，其操作應當對使用者可見；
3.應當限制自動操作的次數和強度，保證人類能超控（override）；
4.應當提供拔電源以外更優雅的關閉方式。
希望人機大戰的悲劇不再重演。
參考文獻
[1] Aircraft Accident Investigation Preliminary Report. Ethiopian Airlines Group. B737-8 (MAX) Registered ET-AVJ. 28 NM South East of Addis Ababa, Bole International Airport. March 10, 2019.
http://www.ecaa.gov.et/documents/20435/0/Preliminary+Report+B737-800MAX+,(ET-AVJ).pdf
[2] Aircraft Accident Investigation Report. PT. Lion Mentari Airlines. Boeing 737-8 (MAX); PK-LQP. Tanjung Karawang, West Java Republic of Indonesia. 29 October 2018.
https://reports.aviation-safety.net/2018/20181029-0_B38M_PK-LQP_PRELIMINARY.pdf
[3] 737 MAX SOFTWARE UPDATE
https://www.boeing.com/commercial/737max/737-max-software-updates.page
[4] Huang P, Guo C, Zhou L, et al. Gray failure: The achilles' heel of cloud-scale systems[C]//Proceedings of the 16th Workshop on Hot Topics in Operating Systems. ACM, 2017: 150-155.
https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/paper-1.pdf