[分享] 獅航737MAX LNI610事故報告重點整理

[kerbi (Before Sunrise)]

獅航MAX事故完整報告重點整理


完整報告：https://tinyurl.com/y6lz2ufp


獅航LNI610事件完整報告已經公佈了兩個多月，
小弟手邊一直有些事情要忙，到這一兩週才開始詳讀。
不讀則已，一讀驚人，
波音設計、認證、獅航組員回報、飛機維修、感應器維修/更換、
組員的訓練、當班組員的處理、航管..等，
全部或大或小，都是起司上的一個洞，
真的不是三言兩語就可以講得完的。

一般沒有相關專業知識的朋友閱讀起來可能會有相當的困難，
即使是飛行員，
如果不是737 on type可能也會在許多地方不好融入情境。

小弟嘗試以我流的方式來解說這份報告的重點之處，
將322頁的報告濃縮到約25頁(PDF)的量。
一些太技術細節的部分可能會省略，
專有名詞的部分也只會解釋個大略的意思，
旨在讓大部分人了解事件的大略脈絡。

小弟自己讀完這份整理的感覺是，
雖然說是濃縮過了，
但訊息量還是有點太大，讀起來還是蠻艱澀的樣子...
不過小弟已經盡力了 (汗)
不充分的地方，歡迎一同補充提問討論。


===所需基礎知識專有名詞解釋===


(已有相關專業知識者可跳過)


攻角 (Angle of Attack, AOA)
翅膀與空氣流的夾角
https://i.imgur.com/ao6J34L.png
太大(或太小)無法提供足夠的升力
https://imgur.com/F8zPMgT


失速 (Stall)
升力不足的現象，主要發生於攻角太大或是空速不足時。


Stick Shaker
即將失速時會發生的警告。
現象為飛行員的操縱桿會高頻率振動，伴隨著大的聲響。


Air Data Inertial Reference Unit, ADIRU
從各個感應器收集數據後執行計算處理的單元，
包括攻角、空速、壓力、高度、外界溫度、位置、姿態..等等相關資訊，
並將這些資訊提供給飛行員的儀器，例如速度計、高度計，
以及飛機的許多自動控制單元，例如自動駕駛、自動油門、自動配平...等。


Pitot Static系統
提供靜壓與動壓的數據給ADIRU處理，
主要用於判斷空速與高度。


Primary Flight Display, PFD
飛行員的主要飛航儀器顯示單元，
主要顯示空速、高度、姿態，航向，自動駕駛狀態..等等資訊。


SPD Flag, ALT Flag
當SPD Flag/ALT Flag在PFD上出現時，代表空速計/高度計有問題。


Flight Director, FD
飛行指引器。
手飛時若有跟隨好其指引，
就可以達到設定的飛航狀態(高度/航向/速度..等)。


爬升下降率
使用Feet per Minute, fpm為單位。
以737來說，
低高度時，爬升率一般大約是500~3000fpm，
低高度時，下降率一般大約是500~1700fpm，
最終進場時，下降率大約600~900fpm。


空速 (Airspeed)
使用knot, kt為單位，即海浬/小時。
以737來說，
低高度無襟翼的話，一般大約為210~250kt，
有放襟翼的話，一般大約是150~210kt。
低高度時，機體最大速限為340kt。


襟翼 (Flaps)
使機翼產生更多升力的裝置，通常是低速(起飛/降落)時使用。
737的襟翼從全收到全放有：UP,1,2,5,10,15,25,30,40
起飛可以使用1~15，通常用5。


配平 (Trim)
調整飛行操控介面的基礎定位角度，
主要目的為減輕飛行員手飛時對於操縱桿上的所需施力。

例如：
飛機在往上飛，飛行員需要將操縱桿往前推才能維持飛機平飛。
而將桿子往前推的動作，
實質上是將尾端的水平尾翼往後仰(可參考上面攻角的圖)。
如果不使用配平，則飛行員需要一直推著桿子才能讓飛機平飛，
而調整配平可以使水平尾翼的基礎定位角度調整到平飛所需的角度，
因此飛行員就不用一直推著桿子，可以減輕所需施力。
反之，飛機在往下飛的時候同理，
調整配平可以讓飛行員減輕維持飛機平飛所需的後拉施力。

三個軸的操控介面都有配平可用，
而本次事件主要專注於俯仰(機鼻向上/向下)的配平。


手動電配平 (Manual Electric Trim)
飛行員手動輸入，使用電動馬達來調整配平，
該電動馬達也為自動配平系統使用。


Speed Trim System, STS
自動配平系統的一員。
飛機的姿態除了會影響飛行軌跡，也會影響空速，
STS的作用為當空速跑掉時，藉由調整配平來讓空速回來。
此系統是背景自動運作，主要作用時機為起飛、爬升、重飛時。


Runaway Stabilizer
控制飛機俯仰的操控介面(即水平尾翼)的自動配平系統發生異常，
主要現象為飛機會自動不停地往上或往下配平，
以至讓飛機進入不正常姿態(俯仰角過大或過小)。


STAB TRIM CUTOUT Switches
有NORMAL與CUTOUT的選項。
切到CUTOUT的話會切斷調整水平尾翼配平的電動馬達，
此時只能藉由飛行員手動轉配平輪來調整配平，
飛機的所有自動配平系統皆無法作動。


Flight Crew Operation Manual, FCOM
提供飛航組員飛機系統知識以及操作程序的手冊。


Quick Reference Handbook, QRH
當飛機有系統異常時，提供飛行員偵錯與解決程序(Checklist)的手冊。


Memory Items
有些系統異常相當緊急，沒有時間讓飛行員拿QRH出來翻，
因此Memory Items為飛行員需要背下的一些初步急救處理程序，
例如失壓、火警、空速不可靠(Airspeed Unreliable)、Runaway Stabilizer..等。
待飛行員執行完Memory Items，讓飛機脫離最危險的狀態時，
再拿QRH出來使用。

Digital Flight Data Recorder, DFDR
紀錄飛行數據的機器。


斷路器 (Circuit Breaker, CB)
作用類似保險絲，可將系統的供電斷開。
電力超載時會自動跳出，也可藉由手動拔出再推回，達到重啟系統的目的。


Crew Resource Management, CRM
利用所有手邊的資源，
分工合作來解決問題的一種思考模式。
簡單來講，
如果我們說CRM好，
指的就是工作分配得宜，溝通清楚順暢，團隊合作良好。


Zulu Time
由於航空是全球性產業，
為了避免時差造成的溝通困難，
提到時間一般都是使用Zulu Time，也就是倫敦格林威治時間。
如果在時間後面看到Z，例如1200Z，指的就是Zulu Time。
而印尼的時區是+7，也就是說，1200Z = 1900當地時間。


Original Equipment Manufacturer, OEM
原廠指定代工生產商，又稱原始設備製造商。


===所需基礎知識點原來這麼多===


(以下提到的飛機皆為發生事故的該架飛機)


2018.OCT.09 事故發生20天前 (P.33)

1159Z 飛機上的維修紀錄頁面
      有記錄到左邊ADIRU偵測到的"攻角數值超出範圍"的錯誤訊息。

1219Z 飛機在雅加達正要parking時，STBY PWR OFF燈亮，
      接著伴隨許多電系的CB跳出。
      (DC BAT, APU GCU, GCU 1, GCU 2, GEN DISC1, GEN DISC 2)

機務將CB推回去，然後讓飛機在怠速運轉下檢查，
之後在維修紀錄本寫下問題已解決。



2018.OCT.26 事故發生3天前 (P.33)

2243Z 在從天津飛往Manado的航途中，
      機長(左側)的PFD上出現SPD & ALT Flag，以及MAINT燈亮。

Manado的機務執行了系統自我測試，顯示通過，於是就簽放了飛機。



2018.OCT.27 事故發生2天前 (P.34)

從Manado往峇里島的航班上，
SPD & ALT Flag又出現在機長的PFD上。
峇里島機務做了跟Manado機務類似的系統自我測試，
顯示通過，於是又簽放了飛機

接著飛機執行了峇里島與Lombok之間的來回航班，Flags沒有出現。

接著飛機又執行了從峇里島到Manado的航班，Flags又出現了
這次機務一樣執行了系統自我測試，結果顯示失敗。
深入檢查後發現許多錯誤代碼，基本上都是跟ADIRU系統相關。
(事實上從26號Flags跳出來開始，
 機務每次檢測到的錯誤代碼都是ADIRU系統相關，
 但是都不盡相同：SMYD FAULT、AD DATA INVALID、STALL WARNING SYS L、
 ADIRU-L ADR DATA SIGNAL INVALID、AOA SIGNAL OUT OF RANGE、
 AIR DATA FROM ADIRU-L INVALID、AOA SIGNAL FAIL ...等)

檢修步驟包含了一個14步驟的偵錯程序，
以及需要針對ADIRU、ADM做Wiring Check，
但機務因為Manado當晚在下雨，
為了避免雷擊所以沒執行Wiring Check。



2018.OCT.28 事故發生1天前 (P.35)

一大早在執行Manado到峇里島的航班前，
機務有與機組人員討論Flags的問題，
(此組機組為前一天晚上將飛機從峇里島飛到Manado的組員)
組員表示此問題已經重複發生多次，要求機務多作檢修，
而機務建議在峇里島進行檢修較為合適。

0205Z 飛機抵達峇里島，
      航途中Flags又出現，並且伴隨SPEED TRIM、MACH TRIM的燈號，
      以及在Manado起飛時自動油門斷開。

峇里島的機務執行系統自我測試，顯示失敗。
進行深度檢查後，發現與前面雷同的ADIRU系統相關錯誤代碼。
接著機務將左邊ADIRU的CB斷開再重新接上後，
執行系統自我測試，顯示通過。

此時機務想要更換攻角感應器來偵錯，但是峇里島沒有料件，
於是與Batam Aero Technique (BAT)公司調貨，於1000Z到貨。

更換攻角感應器後，需要作檢測，(P.36)
方法有兩種，一種是主要的，一種是備用的，
但峇里島也沒有執行主要方法需要的器具，因此機務使用了備用方法：

將攻角感應器分次調到全上、中間、全下，並且紀錄電腦上讀到的各個數值。

但是當時機務並沒有在維修紀錄本上記錄下該數值，
並且在日後的調查時提供了假照片，不被調查委員採信。

然而事實上該新的攻角感應器在裝上前即存在著+21°的誤差值。



更換來的攻角感應器 (P.37)

更換來的攻角感應器，
其實在2017.AUG就曾因為有問題，
而經由BAT公司送給美國佛州的Xtra Aerospace (XA)公司進行檢修。

當時是裝在另一架737的副機長側，
並且在副機長的PFD上出現了SPD & ALT Flags。

XA於2017.NOV將該攻角感應器檢修完成並送回BAT倉庫存放。



Xtra Aerospace公司的檢修方法 (P.89~P.91)

XA公司使用了與OEM不同的機器，Peak API。
儘管生產Peak API的公司有提供證明，
宣稱此機器的效能是相等或更好於OEM的機器，
但根據標準維修手冊裡所述，
執行該檢修只能使用OEM生產的機器，
並沒有說可以使用"相等效能的機器"。
且事實上在後來的調查實驗中發現 (P.202)
Peak API的精確度 (+/- 0.03°)，
其實是不比OEM機器好的 (+/- 0.004°)。

另外，此Peak API與OEM機器相比，
除了ABS(absolute) mode以外，還多了一個REL(relative) Mode，
而且XA公司也使用了這個REL Mode進行檢修。
然而在日後事故後調查時，
並沒有發現有針對Peak API的操作說明，
同時根據NTSB, FAA, Boeing共同測試，
如果在這個REL Mode下進行攻角感應器的檢修，
是檢測不出來誤差值的，
這也就是為什麼更換來的攻角感應器的+21°誤差沒有被XA公司檢測到。



裝上飛機後，備用方法檢測的出這誤差值嗎？ (P.87, P.209)

根據NTSB與Boeing共同測試的結果，
如果裝上有誤差的攻角感應器後，使用備用的檢測方法，
是可以檢測得出誤差的，
加上前述的機務當時沒有在維修紀錄本上紀錄下電腦讀數的行為，
因此無法確認峇里島的機務在更換完新的攻角感應器後確實有執行檢測。



2018.OCT.28 事故前1天，事故的前一段航班LNI043 (P.165~P.168)

在更換完攻角感應器後，當晚飛機執飛了峇里島至雅加達的航班。
在準備時，機務與機組人員討論到關於Flags的事情，
機務與機長說已經更換了攻角感應器，並且測試正常，於是機長接受了。

本航段由機長擔任PF，副機長擔任PM。
行前簡報時，機長有與副機長提到更換攻角感應器的事，
並且這段航班有一位Deadhead組員，也是有737MAX執照的副機長。

起飛過程正常。
收完輪子2秒後，起飛外型警告有出現然後隨即消失。

約400呎時，空速不一致警告(IAS DISAGREE)出現，
並且左邊Stick Shaker啟動，並持續到本航段的最後。
機長將飛機俯仰角飛在+15°，並且保持起飛推力。

機長交互檢查左右PFD與備用儀器，判斷是左邊的儀器有問題，
於是將控制交給副機長，並且call了"Memory Item Unreliable Airspeed"

Memory Items做完後，機長要翻QRH，
此時Deadhead組員跟機長說飛機在往下飛，
機長指示副機長往上飛並跟隨好FD，
副機長說桿子很重，機長指示副機長將飛機配平打好。

機長跟航管表示有instrument problem，宣告"PAN PAN"，
並要求維持跑道航向，航管同意。
幾秒後航管詢問是否想要返航，機長表示"Standby(稍待)"。

此時機長注意到，一旦副機長停止對配平的輸入，飛機就會自動向下配平。
在三次自動往下配平以後，副機長說桿子真的太重了拉不動。

此時機長判斷這個自動往下配平的行為是Runaway Stabilizer，
於是執行了Memory Item，做到把STAB TRIM CUTOUT Switches切掉，
停止了飛機自動往下配平的行為。

幾分鐘之後機長將STAB TRIM CUTOUT Switches嘗試切回NORMAL，
但幾乎是一切回NORMAL的瞬間，飛機又開始自動向下配平，
於是機長便將電門維持在CUTOUT的位置直到落地，
一路上都是用手飛跟手動配平。

組員執行了三個程序:
Airspeed Unreliable, ALT Disagree, Runaway Stabilizer。
這三個程序都沒有指示"要就最近的適合的機場落地"，
因此他們就維持28,000呎繼續前進。

機長還注意到，他的速度計上的失速跟超速的紅黑bar連接在了一起，
(總之在低高度不會發生這件事
 而在高高度發生的話代表也飛到一個不該飛到的高度了)
並且從上到下佔滿了整條速度計。

在1556Z 飛機順利於雅加達降落。

飛行資料記錄器記錄到，落地以後手動電配平又被使用了，
這代表組員將STAB TRIM CUTOUT Switches切回NORMAL的位置。

停好飛機後，
機長在維修紀錄本寫下IAS DISAGREE、ALT DISAGREE、
以及FEEL DIFF PRESS這三件事，
但是他並沒有提到Stick Shaker從頭啟動到尾，
也沒有提到他們有將STAB TRIM CUTOUT開關切到CUTOUT位置，
然後落地後又切回NORMAL的事。



LNI043落地後的檢修 (P.177)

根據機長在維修紀錄本理提到的三件事，機務做了相對應的檢修，
但是機務這次卻沒有將檢測出的相關錯誤代碼紀錄在維修紀錄本中。

檢修的範圍主要是針對Pitot Static系統，
在檢修後PFD上Flags消失，根據手冊上說這樣系統就是正常的，
於是機務便簽放了飛機。
在這個檢修中有包含攻角感應器的目視檢查，但不包含重新測量讀數的檢查。
因此攻角感應器存在誤差的問題還是沒被發現也沒被解決。



MCAS之設計與作動條件 (P.48~P.50, P.189~P.202)

由於在NG系列的機身上裝上了更大的引擎，
並且調整了引擎位置與重心，
因此MAX系列在設計階段即被發現有仰角過高的風險，
波音進而設計了MCAS系統。

MCAS是Speed Trim System下的一個子系統，
其目的為抑制飛機仰角過高的問題，
進而避免攻角過大而失速的狀況。
其作動條件為：(1) 手飛, (2) 襟翼收起, (3)攻角過大
在這條件下MCAS會幫飛行員壓機鼻，
進而達到降低攻角的作用來防止失速。

當MCAS作動時，可以被飛行員藉由使用手動電配平停止，
並在5秒後會reset 該系統。

737系列有在控制桿模組上有一個Column Cutout Switch裝置，
包括MAX系列也有，
其功能為自動配平系統以及手動電配平的配平方向，
不能與操縱桿的相反方向去調整。
例如，當桿子往前推，是想將機鼻往下，
那麼此時飛機的自動配平系統或是飛行員，就不能打讓機鼻向上的配平。

但是MCAS的設計卻需要打破這個原則。
因為波音是假設飛行員手飛時，
桿子往後拉太多導致的機鼻太高攻角過大，
因此需要MCAS往下配平來讓機鼻往下。
所以當MCAS作動時，會將其功能屏蔽掉。
(屏蔽桿子往後拉時的cutout)

另外，在737 NG系列的PFD上，
當攻角不一致時，會有"AOA DISAGREE"的警告訊息，
但是MAX系列卻將這個功能拿掉，
必須有選配攻角顯示器(AOA Indicator)才會有此警告訊息。



MCAS之認證 (P.189~P.202)

在設計最初，波音令其只有配平水平尾翼頂多0.6°的權限，
影響機身俯仰程度最大至4.2°，
不過測試結果發現0.6°不夠抑制，
於是最後放寬至2.5°

但是這個放寬行為卻沒有更新至所有波音送審的文件，
亦即，當MCAS已經修改成2.5°的版本時，
FAA審的卻還是0.6°的版本。

波音執行MCAS異常作動的危害等級評估時，做了以下四個假設：
  ．MCAS錯誤的作動會被組員確認
  ．MCAS完整作動一次，組員仍可以只用操縱桿維持飛機操作
  ．組員會即時地將飛機配平回平衡狀態，將施在操縱桿的力量釋放
  ．使用現有的Memory Item可以應付MCAS的錯誤作動

基於以上假設，
波音評估MCAS異常作動時的危害等級是Major，
(總共四個等級，由輕到重為Minor, Major, Hazardous, Catastrophic)
此等級並不要求波音執行更加嚴格的危害分析推演。
但是，其評估基礎為0.6°的模擬而不是2.5°，
並且也沒有考慮當MCAS重複地錯誤作動時的效應。(P.190)

波音的工程師與試飛員討論後認為，
MCAS的多次錯誤作動與單次錯誤作動並沒有什麼分別，
因為他們假設飛行員每次都會使用足夠的配平量來抵銷MCAS的錯誤輸入。

Major等級也不要求使用另一個訊號源來交叉檢查訊號的正確性，
因此MCAS被設計為依賴單一攻角訊號來作動。

此外，在波音與FAA討論MAX的訓練與手冊的過程中，
波音建議將MCAS從FCOM及差異表中拿掉，
理由是MCAS是在背景自動運作，並不需要組員操作，
並且現有程序可以處理MCAS的作動或是異常作動，
組員也不會在正常情況下遇到MCAS作動。

但是事故發生的情境並不在這些討論之中被考慮，
而且獅航的兩次事件中，
組員們的表現也並不像波音預期般的假設。



2018.OCT.29 事故當天，事故當班LNI610 (P.19~P.27, P.79~P.85)

本航段由機長擔任PF，副機長擔任PM。
行前簡報時，
副機長表示他是早4點接到電話改班，
而機長表示他感冒中。
他們討論到ADF(一種導航儀器)不能用、巡航高度選擇FL270、天氣很好，
但是並沒有討論到關於在維修紀錄本裡記載的之前的那些Flags的狀況，
也沒有討論到攻角感應器更換的事項。

在跑道上加速起飛時，
DFDR記錄到兩邊的攻角數值差了約21°，
並且機長的FD俯仰指示在-1°，而同一時間副機長的指示在13°

離地2秒後，左側的Stick Shaker隨即啟動，
緊接著短暫的起飛外型警告響起，以及空速不一致的警告跳出。
左右空速計分別為164 & 173 kt

此時副機長馬上疑問飛機怎麼了，並且詢問機長是否想要返航。
機長沒有回答問題也沒有任何表示。

30秒後，副機長表示高度不一致警告跳出，機長抄收。
左右高度計分別為340 & 570 ft
副機長與航管聯絡，並詢問航管在雷達上看他們高度是多少，
航管回答900 ft，而此時左右高度計分別為790 & 1040 ft。

機長接著指示副機長執行Memory Item Airspeed Unreliable，
副機長沒有回應。

過了幾秒，副機長問機長想要飛什麼高度，並且建議飛向跑道的downwind，
此建議被機長拒絕，並指示副機長向航管要求一個待命點待命。
於是副機長向航管要求一個待命點，並表示他們有"Flight control problem"。

航管事後表示只記得他們有回報飛操問題，沒有記得他們有要求待命點。

約10秒後，副機長問機長要不要收襟翼到1，機長同意。
接著機長要將控制交給副機長，但副機長表示"Standby"。

此時航管注意到他們的高度從1700下降到1600，於是詢問組員想要的高度。
左右高度計分別為1600 & 1950 ft

又過了約10秒，副機長建議機長將襟翼收到UP，機長同意。
副機長並詢問機長是否想要爬6000呎，機長說5000。
於是副機長跟航管要求5000呎，航管同意並請他們左轉到航向050。
左右速度計分別為235 & 251 kt

約10秒後，襟翼收完，自動的向下配平啟動約10秒，
水平尾翼的角度從6.1變成3.8。

8秒後，機長指示將襟翼從UP放回到1，接著使用手動電配平往上打了5秒，
角度從3.8慢慢回到4.7。

3秒後，出現一陣下降率3750fpm的下降，高度減少600呎。
接著襟翼到達1的位置，Sticker Shaker短暫停止。
此時左右攻角紀錄分別為+18° & -3°，
而飛機以3200fpm的速度下降。

接著，出現一波8秒的自動向下配平。

副機長問航管雷達上顯示他們的速度多少，
航管表示地速是322kt，同時間飛機上的低速警告"AIRSPEED LOW"響起。
左右空速計分別是306 & 318 kt

組員將襟翼選到5，機長又往上trim了大約5秒，
水平尾翼角度來到4.8。

接著左邊Stick Shaker又開始啟動，
飛機以1500fpm的速度爬升，俯仰角約為+3°。

此時機長的空速計上失速跟超速的紅黑bar連接在一起，
副機長的超速紅黑bar出現，底部是340kt。
機長命令"Memory item, memory item"

8秒後，副機長問是要做什麼memory item，機長回答"Check"
17秒後，副機長問"Flight control?" 機長回答"Yeah"

副機長開始翻QRH，10秒後說"Flight Control Low Pressure.."
左右高度計為 4110 & 4360 ft

副機長繼續翻了20秒，然後說"Feel Differential Pressure.."
機長此時指示副機長做Airspeed Unreliable

副機長繼續翻了25秒，然後表示他找不到Airspeed Unreliable在哪裡
左右高度計為4900 & 5200 ft，爬升率1600fpm

過了約20秒，航管指示左轉航向350，爬5000呎，副機長抄收，
然後襟翼又被從5收到1的位置。

副機長再次表示QRH裡面沒有Airspeed Unreliable，
然後襟翼被收到UP。
駕艙錄音器沒有錄到關於襟翼位置的討論。

過了幾秒，
也就是機長初次指示的3分40秒後、再次指示後的1分12秒後，
副機長找到了Airspeed Unreliable並開始念。

10秒後，MCAS啟動2秒，被機長的往上配平打斷，角度來到6.19。

接下來是機長與MCAS的對抗 (數字越小就是機鼻被壓越多)

往下6秒 -> 往上8秒 -> 6.27
往下7秒 -> 往上6秒 -> 5.59
往下4秒 -> 往上4秒 -> 5.6
往下3秒 -> 往上3秒 -> 5.0
往下3秒 -> 往上6秒 -> 5.83

這中間穿插著航管的航向指示，以及副機長在念程序

往下5秒 -> 往上6秒 -> 5.5
往下4秒 -> 往上7秒 -> 5.7
往下7秒 -> 往上7秒 -> 5.3
往下1秒 -> 往上3秒 -> 5.4

繼續穿插航管指示，以及副機長在念程序

往下4秒 -> 往上6秒 -> 5.7
往下6秒 -> 往上5秒 -> 5.0
往下7秒 -> 往上9秒 -> 5.4

左右高度計為 4770 & 5220 ft

往下4秒 -> 往上7秒 -> 5.6
往下6秒 -> 往上3秒 -> 4.5

副機長聯絡近進航管說有飛操問題，
航管給予航向指示並請他們預備跑道25L落地。

往下2秒 -> 往上6秒 -> 5.1
往下6秒 -> 往上9秒 -> 5.5
往下5秒 -> 往上3秒 -> 4.8

此時機長交控制權給副機長 (紀錄結束前約1分鐘)

           往上3秒 -> 5.4
往下8秒 -> 往上1秒 -> 3.5

副機長表示控制很...

往下3秒 -> 往上1秒 -> 2.9
此時桿子上的重量是65lb (約30kg)

           往上4秒 -> 3.4
往下8秒 ------------> 1.3
此時桿子上的重量是82lb (約37kg)

此時飛機的俯仰角是-2°，下降率是1920fpm
副機長表示飛機在往下飛，機長表示"It's ok"

           往上2秒 -> 1.3
往下4秒 ------------> 0.3

此時桿子上的重量是93lb (約42kg)
左右高度為 3200 & 3600 ft
下降率為10000fpm

近地警告"TERRAIN TERRAIN"、下降率過大警告"SINK RATE"響起。

紀錄停止。

.
.
.

機長基本資料與訓練紀錄 (P.28)

年齡：31
總飛時：6028 hr 45 min
737飛時：5176 hr

檢視從2011年開始的訓練紀錄，
每一次考核都通過。

訓練紀錄中有一些註記：
2015.MAY  "最後進場時失速"的處理缺少適宜技巧

2017.MAY  CRM需要加強

2018.MAY  加強項目"團隊合作"：
          使用標準術語來進行有效溝通，而從在緊急情況時有好的團隊合作



副機長基本資料與訓練紀錄 (P.29~P.31)

年齡：41
總飛時：5174 hr 30 min
737飛時：4286 hr

訓練紀錄註記：
2013.JUN  考核fail。
          非精確進場時忘了程序，錯失下降時機；
          重飛時對於自動駕駛系統的理解上有問題。

2013.JUL  再次考核有15個加強項目。
          在"基本飛操"與"失速處理"被註記需要更好的技巧。

2013.JUL  需要更加理解程序。
          "起飛後引擎故障"項目考了第四次才通過；
          在單引擎操作時需要更好技巧；
          單引擎進場時需要跟隨好FD；
          缺乏情境警覺。

2014.JUN  最終進場時有"嚴重問題"，太心急，需要更細膩的操作。
          對於外界條件(例如風)改變時的操作要更加強。

2014.JUL  高過標準離場程序初始高度；
          "非正常情況程序"找錯項目；
          非精確進場最後進場階段沒有跟好下滑路線。

2016.FEB  加強項目"非精確進場"，於最終進場時保持飛機直飛有困難。

2016.AUG  ILS進場手飛控制飛機時有困難

2017.AUG  ILS進場時交叉掃描儀器太慢

2018.APR  情境警覺需要加強

2018.AUG  開車時溫度超限，情境警覺需要加強


===實驗與研究===


主要列出一些結果 (P.92~P.93)

(一) MCAS作動時的表現與STS作動的表現很類似。
     (與傳統上的Runaway Stabilizer不同：
      STS是間歇性地配平，Runaway是連續不斷地配平)

(二) 模擬事故航班的狀態，
     即有Stick Shaker + 空速不一致 & 高度不一致。

     如果保持起飛襟翼 (Flaps 5)，
     此時MCAS並不會啟動，
     可以完成Airspeed Unreliable 與 Altitude Disagree程序，
     並回雅加達成功落地。

(三) 同樣模擬事故航班狀態，但要將襟翼收到UP，
     觀察Runaway Stabilizer程序對MCAS的效用。

     結果是在MCAS的啟動下，使得飛機操控變得相當困難，
     但是使用足量向上配平還是可以控制飛機，
     並且在做完Runaway Stabilizer程序後，
     MCAS的問題就解決了。

(四) 完全模擬事故航班狀態，
     即Stick Shaker + 空速不一致 & 高度不一致，
     襟翼收到UP，
     前段使用足量向上配平，後段使用不足向上配平，
     並且對航管指令做出回應，

     在這些條件下觀察到以下情形：
        ．如果不使用足量向上配平，則高度不能維持
        ．重複的MCAS作動使組員工作負荷大幅增加
        ．航管指令相當干擾
        ．很難完成Airspeed Unreliable程序

(五) 不輸入向上配平的情況下感覺MCAS的影響：
     在MCAS一次完整作動後，即需要相當大的後拉力才能維持控制飛機；
     在MCAS兩次完整作動後，基本上就拉不動桿子了。

另外，在襟翼全收的情況下，
手動電配平的配平速度是Low Rate，(P.47)
而MCAS與STS的配平速度都是High Rate， (P.49)
意即組員要使用更多的時間來打反向配平才能抵銷MCAS的輸入。


===分析與結論===


前一航班LNI043組員 (P.174)

前一航班的組員遇到了與事故航班組員一樣的狀況，
但是他們卻成功地將飛機落了地。

(一) 情境警覺
     面對一離地後的Stick Shaker，
     機長將俯仰角度維持在+15°，並保持起飛推力。
     接著將控制了交給副機長，
     指示了Memory Item Airspeed Unreliable，
     並指示副機長跟隨好FD，打好配平，
     以至於他有更多空間去分析整個情況。

     而在Deadhead組員指出飛機正在往下飛的時候，
     機長很快地發現了水平尾翼的自動配平有問題，
     因此將STAB TRIM CUTOUT Switches切斷，
     讓他們得以控制住飛機。


(二) 問題回報
     機長於落地後的報告內沒有完整地回報問題，
     (缺了Stick Shaker與STAB TRIM CUTOUT)
     有可能導致了機務對飛機狀況的評估，
     這是因為機長對系統異常與發生現象之間的關係的認知並不完全。
     儘管如此，
     沒有完整回報的行為還是不符合作業守則上的要求。



LNI043落地後的雅加達機務 (P.177)

(一) 沒有將檢修時偵測到的錯誤代碼記錄下來，
     可能代表他們沒有看到或是沒有去看錯誤代碼，
     有可能影響了他們對飛機狀況的判斷。

(二) 執行了IAS DISAGREE與ALT DISAGREE的檢修，
     但是這兩者的檢修重複性高並且對於解決問題沒有幫助。

(三) 對於AOA感應器只有要求目視檢查而沒有重新測量檢查，
     也導致了21°的誤差值沒有被發現。

(四) MAX取消了AOA DISAGREE的警示是不符MAX系列飛機認證的內容，
     但是波音與FAA都沒有發現。
     不過波音指出，缺乏這個警示不會影響機務的偵錯，
     機務方面的錯誤代碼，例如stuck AOA、bent AOA，還是可用的。



事故當班LNI610的組員 (P.178)

(一) 組員的訓練與專業性
     在空速不一致出現後，
     機長指示副機長執行Airspeed Unreliable的Memory Item，
     但是副機長卻沒有執行。
     (其實這邊也很奇怪
      Airspeed Unreliable的Memory Item
      是PF，也就是機長本人要執行
      此時機長還沒交出控制，不知道為什麼是叫副機長執行)

     在機長最初的指示約兩分鐘後，
     副機長都還是不清楚要做什麼Memory Item。
     又過了約一分鐘，副機長再次詢問要做什麼，
     機長再次回答Airspeed Unreliable。
     副機長開始翻QRH，但是一開始卻翻不到，
     又再過了一分鐘，副機長才翻到Checklist並開始念。

     Airspeed Unreliable Checklist的所在頁面就寫在QRH的封面上，
     並且Memory Items應該是在拿QRH出來翻以前就要憑記憶執行的動作。
     副機長不僅不確定是要做哪個Memory Item，
     即使確認了也背不出來，翻也翻不到，
     顯示了副機長對於非正常程序不熟悉，
     也符合他的訓練紀錄備註。

     事實上事故當下的狀況也不符合程序中的條件。
     程序內提到，要判斷空速是否一致 ，
     必須在飛機配平穩定的情況下再做判斷，
     (即使穩定了，也必須差20kt/0.03M以上才視為不一致，
      而當下紀錄左右空速最大差距其實也只有15)
     以當下MCAS重複錯誤啟動的狀態，
     基本上是無法達成條件。
     而由於工作量繁重，
     他們直到最後也無法完成Airspeed Unreliable的程序。

     在前面機長還在控制飛機時，
     機長有使用較足的向上配平去抵銷MCAS的輸入，
     使配平角度基本一直維持在5.0以上。

     控制交給副機長的當下，
     右邊高度顯示5900ft，水平尾翼配平在5.4。
     幾秒鐘之後MCAS作動8秒，
     使配平從5.4降到3.4。
     副機長表示控制很不正常，
     但是並沒有清楚地說出來哪裡不正常，
     然後往上打了一點配平 來到3.6。

     隨著MCAS的重複作動以及副機長的往上配平不足，
     配平角度越來越小，
     直到最後在桿子上的重量到達103lb (約46kg)。

     正常飛行員對於桿子很重的第一反應都是使用配平，
     機長的訓練或是經驗使他能使用足量配平，
     但是副機長卻沒有，
     這也與副機長的訓練紀錄內容相符。
     (對737而言，最後進場階段的操作會經常使用配平。
      訓練紀錄多次在最後進場階段的註記，
      顯示副機長對於操作飛機確實有相當程度的困難與不熟悉)
     雖然獅航對此有實施加強訓練，
     但顯然成效不彰。


(二) 組員的工作負荷 (P.180)
     在襟翼沒有收完以前，
     組員的工作負荷是很高，但是是可以處理的。
     但收完以後，MCAS的重複作動，
     使組員工作負荷大增。

     從機長對副機長的極簡回答或無回應、無法維持航向高度、
     無暇管理油門及速度、以及無暇給予收襟翼指示這幾點來看，
     機長的工作負荷是相當高的。

     另外，航管的指示也大幅增加了組員的工作負荷。
     在組員回報有飛操方面問題後，
     航管依然給予了8次的航向指令。

     這是因為在印尼的航管手冊裡，
     飛操問題並不列為緊急狀況，
     (但是儀器問題有列為疑似緊急狀況，而LNI043就是回報了儀器問題)
     加上組員沒有宣告MAYDAY或是PAN PAN，
     所以航管並沒有將LNI610的管理等級列為優先，
     若有列為優先則不會給予那麼多的指令。


(三) 組員對飛機狀態的認知 (P.181)
     前一班LNI043的組員有簡報到之前連續發生的Flags事件，
     有可能因此幫助到他們較為迅速作出了判斷；
     而LNI610的組員在行前簡報時卻完全沒有提到，
     沒有心理準備，有可能因此影響了判斷。

     在飛機發生異常狀況時，
     組員會依照訓練使用程序來偵錯與解決。
     但是在事故航班的情況下，
     程序並未能完成，
     這也造成組員判斷上的困難。

     當MCAS作動時，(P.197)
     並不像傳統的Runaway Stabilizer是連續不間斷地配平，
     而是像STS一樣，間歇性地配平。
     如果在一般環境下，還是算容易被察覺的，
     但是在事故航班的環境：
     多重警示訊號、燈號、Sticker Shaker聲響、
     以及組員的注意力被各自的任務佔據(控制飛機、念程序)的情況下，
     的確有可能不會被組員注意到。

     兩個航班的機長都在2~3秒內對MCAS作出反應：(P.193)
     往後拉控制桿以及使用手動電配平。
     但前一班LNI043的組員花了3分40秒才發現問題在哪裡，
     並切斷配平馬達，
     而事故航班的組員則是到最後都沒有發現問題在哪裡。

     另外，組員是在前一版的737(NG)為基礎上訓練的， (P.181)
     該版本有攻角不一致(AOA DISAGREE)的警示，
     而MAX版本將此警示拿掉，
     也有可能因此造成組員沒考慮可能是攻角感應器有問題。
     (加上行前也沒有簡報到攻角感應器有更換的事項)

     而向ATC詢問高度的行為代表飛行員與航管都不清楚原理：
     航管雷達上的高度是由飛機上傳輸訊號出去的，並不是雷達偵測的，
     因此航管看到的高度並不比飛機上的高度計可靠，
     聽到航管報的高度可能會讓組員誤判高度計是可靠的。

     最後，
     FCOM與訓練過程皆沒有提到關於MCAS的資訊，
     也可能造成組員判斷狀況上的困難。

(四) CRM (P.182)
     機長並沒有清楚地分配組員間的任務，
     或是清楚地講出要去哪裡待命，
     以及要如何解決問題的計畫；

     對於副機長的提問或是建議，
     機長也都是極簡回答或是甚至沒有回應；

     副機長對於機長悖離航向或是高度時也都沒有提醒；

     而機長在將控制交出去給副機長時，
     沒有清楚交代控制上的困難，
     以及操作上的重點；

     兩位組員分別專注在自己的任務上，
     之間缺乏清楚的溝通，使他們的認知有落差。

     機長的這些表現也符合他的訓練紀錄註記。


===好長，超過一萬字了===


會整理這份報告，
主要也是小弟想知道究竟發生了什麼事情，
順便看看與小弟當初的猜測有幾分相符， ( #1So35pa1 )
並且釋疑解惑。

媒體報導的內容雖然正確，
但由於過度簡化，
還是容易造成大家的理解不完全。

在此小弟也不做過多的心得與解釋，
只希望飛安能夠越來越好，
快樂出門，平安回家。

以上，歡迎一同補充提問討論。

Peace。


--
    青  ╱￣￣＼        黃 ∕￣￣￣﹨         赤  _MARINE_
    雉 |◤╳╳◥|*      猿 |◤====◥|         犬 ◣      ◢
      （ ●﹀● ）           ⊙▇⊙              ╲●︺●／
    ※○◣ ︽ ◢○         |◣/︾\◢       ▂▌◥◣\ ︿ /◢
    ◤ ︶/◥◤\︶        ─X-/◣◢\        ▂▂     :▼@\
   ◢◣▂  ▃              |  |▃|         ▂▂  ◢  ▃       ψyang0515

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.133.119.64 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Aviation/M.1577976322.A.8E9.html
推 peterj0727: 推 在印尼工作時常坐較便宜Lion air
推 axyl: 認真推
→ peterj0727: Garuda Indonesia貴了3倍以上啊
推 peterj0727: Sriwijaya Air也不錯，鷹航的子公司
推 Tamama56: 推
推 souken107ttc: 推
推 weng0216: 推
推 yechu2003: 專業推
推 james7890: 推推，辛苦了
推 michael1989: 推整理及分享
推 jjjfar: 推
推 twflanker: 推
推 hambear: 推
推 MPSSC: MCAS的2.5度評估,就是很典型的FMEA評估有問題....
推 shen5035: 這不推不行！
→ MPSSC: 以工程角度來講,波音這種FMEA評估無異於蓄意害人....
推 edison: 推
推 HMKRL: 推 非常清楚
推 donkilu: 推整理 寫得很清楚
推 tilasmi: QQ認真推
推 SxF1SR: 推 資料非常齊全足以明瞭完整的真相
推 astushi: 再次證明飛安事故發生原因都是一連串的不會是單一原因造
→ astushi: 成事故
推 gieat: 一邊看一邊心跳很快...，大推
推 chewie: 推 系統害人 遇到較有能力的組員還有機會能力解決 運氣不
→ chewie: 好就...
推 cerbecoyote: 推
推 JLurker: 推
推 PatrickStar: 推整理
推 etemenanki: 太強了！推專業
推 SniperF: 好文推，感謝用心分享。
推 HMKRL: 求這集的ACI
推 karenjiangha: 推
推 yuki166618: 退用心
→ yuki166618: 推才對，選字選錯
推 faaQ: 專業推
推 flymonkey:  感謝分享 推！
推 odintoby: 推！感謝整理！
推 utamaru: 推
推 PsMonkey: 超認真
推 wdnm3444: 感謝整理
推 zeta: 推，唉......
推 w92056frps: 推
推 tilasmi: 看完，再推一次
推 a880338: 推
推 acomp: 推
推 sherlockt: 各種起司鑽洞 看得小弟瑟瑟發抖
推 aaaaa123880: 推 專業整理
推 NiChu: 好猛的讀書心得筆記.........
推 ting445: 推認真整理 好用心 繼續等衣航的報告...
推 sam749: 推 太專業了
推 tofupudding5: 先推再看
推 Stan6003: 推
推 duckbill37: 看完推!
推 wojciech: 推詳細資料
推 jack82822005: 推QQ
推 kimberly: 有看有推 謝謝清楚整理
推 seazilicy: 太強了...
推 clallg: 專業推，謝謝整理
推 ATR72: 感謝用心整理和分享
推 qashty: 看完默默把memory item默背幾次
推 rangercat: 推
推 wouo: 推
→ shizxc: 用心推
推 jay70134: 推 好厲害
推 shizxc: 補推
推 AtDe: 推
推 ichiro0805: 推
推 fluterway: 好專業
推 heigleck: 必推，現在社會普遍缺少收集資訊仔細判讀的習慣，只想速
→ heigleck: 成，這文章太好了
推 qqquen: 推 外行人也略懂略懂了
推 amethystboy: 跪著看完
推 JackChung: PPL跟IR訓練時教練都ㄧ再強調要trim好
→ JackChung: 不要試著靠自己的力量跟elevator鬥 @@
推 ggyyhippo: 前一班如果沒有那個DH組員，搞不好就換人失事了 囧
推 ilovejesus: 推
推 cinther129: 推
推 APC: 推
推 nasacs168: 專業推，果然會導致這麼嚴重的事故其問題永遠不只有一
→ nasacs168: 個
推 APC: 同樣問題，遇到不同人的結果大不同
推 VGuerreroJr: 長知識! 感謝專業分析 推推推
推 aoinosora: 專業推！！
推 FlynnZhang: 感謝整理 先推再看
推 ac135211: 推
推 as74155: 先推再看
推 twgene: 推
推 jjwei: PUSH
推 nthukos: 推
推 FFtera: 推
推 a25172366: 推
推 Jelen: 推
推 p3: 推~長知識了~
推 tudaer: 推用心整理和解說
推 jlist: 強
推 aikrod8155: 推
推 injuju: 推用心 感謝整理
推 birdman4368: 認真分享推
推 f1266208: 推
→ EEspresso: 哇  這篇好神   收藏慢慢看
推 atrix: 推
推 birdruei: 謝謝分享
推 blue2999: 推
推 aksurfgg: 感謝分享
推 kevabc1: 推整理和解說及給新手的詞庫
推 yofute: 優質文～～推
推 uufo8118: 推專業
推 redcent: 專業推
推 taxlaw1991: 推爆
推 noryb: 推! 謝謝分享!
推 toojooken: 大推
推 Aueston: 推 超專業 看完了解很多
推 Majini: 推整理 基本上就是設計缺陷+訓練不足。
推 edwinfan1974: 已收藏，有時間再慢慢看^^
推 pingupapa: 推
推 threebangz: 推
推 polardior: 推整理！
推 juanesrule: 推專業整理
推 chris0720: 推
推 TsukimiyaAyu: push
推 okim: 推!
推 DMF: 專業推！！！！好強大
推 Loveis5566: 好絕望....
推 TF00207374: 推
推 s6263565: 推！
推 gman1975: 請收下我的崇拜！！
推 salo: 好文 推！
推 yah02142000: 推
推 heremattis: 推
推 kikiks: 先推 晚點看
推 cpstrvl: 不推不行
推 driver0811: 推，感謝
推 summerleaves: 認真推 中文寫得不錯
推 joson4921: 推
推 weewee: 推..
推 Laviator: 專業推…請收下我的膝蓋！！
推 ericwhps: 專業推
推 MGGB: 推
推 wawa456654: 推
推 anarch: 謝謝您!
推 driver0811: 推，精簡後如同文字版空中浩劫
推 skyteam55535: 推爆
推 ylc: 男神必推 這太猛了
推 coconew: 大推！
推 angelicF: 推推
推 Hans8251: 有空中浩劫旁白的聲音浮現...
推 dahlia7357: 神 有畫面
推 qwe753951: 不推不行
推 aadsl: 先推再看
推 callresa: 謝謝整理！
推 appaz8209: 推
推 Archerfish: 推，看完有點難過
推 aadsl: 看完覺得機長真的很重要
推 james7751: 推整理 辛苦了
推 lawrence7373: 對，不過起司模型已經落伍了
推 MIKEmike07: 太厲害了 推
推 mike0926: 推
推 imperator999: 專業推
推 lucasboy: 推
推 lingar: 推
推 yamakazi: 看起來跟軟體程式沒什麼太大關係
推 Za: 專業推 看完一身冷汗
推 cyberpoli: 推
推 sky781125: 推
推 gitans: 推，沒專業知識的我也稍微有概念了，謝謝！
推 SAUN: 超棒的整理，太專業了
推 HENRY1: 推
推 masknest: 感謝整理 推
推 GFGF: 推
推 heinrich: 推
推 assanges: 最後一班機組就真的帶賽鬼
→ assanges: 一方面綜合能力稍遜 另一方面也沒有獲得充足資訊
→ assanges: 切開根本就卡門貝爾流心的 (嗯好吃？
→ assanges: 不愧是用波音的併購起來的麥道
→ assanges: *的錢  前面的評估根本沒發現錯誤
推 urmine10: 大推整理文
推 stanleyjou: 真的是專業，不得不推好文
推 Seiran: 推
推 seabigman: 推實在寫得太詳細 我這個門外漢也看得有幾分了解
推 aksone: 好文，推!
推 nyrnu: 感謝整理 推
推 KHHSam: 整理的太詳細了，推！
推 TBOC: 感謝整理
推 sunnyabe: 推文字版的空中浩劫
推 appleonatree: 推 超詳細
推 s5520316: 推！
推 wonderlands: 文字版空中浩劫
推 Marqquet: 超威
推 TrueTears: 推
推 yuinghoooo: 軟體依然是禍首，是因為沒有正確處理才導致墜機，機
→ yuinghoooo: 組判斷正確可以救回來
推 bluegtv: 專業及認真!
推 quaketw: 推
推 ljimmy85: 專業推
推 Chiardy: 神級的整整理和翻譯功力！還順便幫小弟複習了738系統，
→ Chiardy: 謝謝！
囧，說到系統誰比得上C教官，
教官您才是真正神級啦！
小弟我還需要多多努力進步，
跟C教官看齊！！

推 an9wang: 專業推！
推 paselalps: 推
推 tony900735: 推
推 Bigblackoo: 先推以後也不會看 反正也看不懂
推 ssaume: 跪讀
推 gemilay: 推
推 s5689: Boeing:我們的飛機都很乖，飛行員要自己注意配平啊
推 rayccccc: 知識+++
推 A380: 先推 感謝整理
推 sulichun: 我媽問我為什麼跪在電腦前面。
推 Dakoter: 扯爆
推 BrokenYume: 推
推 s0322008: 推~
推 gregyeh: 專業推!
推 yayapapapa: 哇IP的料
推 chitsaijang: 推
推 donatello: 推，感謝翻譯整理
推 Hod: 太專業啦！
推 ming01011004: 推
推 chihsen3: 推
推 vollenca: 好專業呀！大推。
推 extrachaos: 推
推 yagmaiboyi: 推 專業
推 crimsonn: 推!!
推 fago1sback: 大推！看著看著都緊張起來了
推 hellowin: 太專業了！
推 kidlily: 謝謝整理，有條不紊、易讀性高，外行人也能略知一二
推 fanuc: 這我還不推爆
推 MarbaUil: 真的邊看邊心跳加速！
推 blueview: 推原po 長知識了
推 alexchen0301: 專業推一個
推 ARIanayew: 航空版藏神人
推 huangkai: 推
推 teddy1209: 看了單單回來看
XD
單單頻道聊聊本次事件：https://youtu.be/-eHAu-c77kQ

→ crazy80: 推
推 mobile86: 朝聖推
※ 編輯: kerbi (220.133.119.64 臺灣), 02/22/2020 19:51:08