當完美代碼撞上物理時差：一次僅一秒的彈跳，如何讓空客A320瞬間腦死亡

之前有不少粉絲留言催我寫A320，找了一圈材料，最后還是決定從這個案例入手。

「飛機的賬本」這一期，拆一架沒有任何硬件損壞、沒有任何代碼bug、五臺飛控計算機卻在毫秒內集體自我關閉的空客A320。真正把它們逼上絕路的，不是芯片故障，是物理世界的時間精度和數字世界的邏輯之間，那道永遠彌合不了的裂縫。

一、塔林跑道上的十秒鐘

圖1:ES-SAN ，事故中的那架 A320 。它真正失去的，不是發動機，也不是機翼，而是俯仰控制鏈路。

2018年2月28日下午，愛沙尼亞塔林機場。

一架靈貓航空（SmartLynx Airlines Estonia）的空客A320，注冊號ES-SAN，正在跑道上做著陸連續訓練。左座是一名正在接受改裝的飛行員，右座坐著一名資深的飛行教員，客艙里還坐著4名隨行機務。

15時05分，飛機觸地。

右座的飛行教員在降落前沒有按標準程序預位地面擾流板。機翼上的升力沒有及時卸掉，主起落架在觸地后發生了一次反彈。

這種反彈不算什么稀奇事。通航訓練里更是常見，就算是A320，每天在全世界有幾萬次起降，偶爾彈一下也屬于日常。

在觸地反彈后，飛行教員隨即接管了操縱桿，推力手柄直接推到最大，準備拉起復飛。飛機剛剛離開跑道，還沒來得及建立穩定爬升，駕駛艙就炸了鍋了，主警鈴響起，PFD（主飛行顯示器）上跳出一行紅色警報：

MAN PITCH TRIM ONLY

圖2:A320 的中央操縱臺。事故中，飛行員最后能依靠的，就是這里那組平時很少被人真正救命式使用的配平手輪。

飛行教員本能地把側桿向后拉到底，試圖拉起機頭，不過沒有反應。

飛機左右升降舵卡在0°中立位，一動不動。側桿不管拉多大的幅度都一樣，電傳操縱系統已經完全斷開了和升降舵的連接。

在接下來的十幾秒里，這架60多噸的空客客機的狀態非常反常，橫滾方向還能控制，但是決定飛機抬頭還是低頭的俯仰方向，已經完全失去了響應。飛行員唯一還能用的，就是中央操縱臺旁邊那個平時幾乎沒人去碰的配平手輪，機上的機組試圖拉動水平安定面，一圈一圈地把飛機姿態救回來。

就這樣，一架2018年的電傳客機，被迫用回了純手操。

圖3:現代電傳客機被打回機械時代：當升降舵不再響應側桿，配平手輪成了最后一根機械繩索。

二、五臺電腦和一管潤滑油

要理解這架飛機為什么會突然發生"腦死亡"，需要先看看空客給A320設計的這套中樞神經。

A320的俯仰控制是完全靠電信號的。

飛行員拉桿，信號先走計算機，計算機算完了再告訴液壓閥門該怎么去推舵面。這就是電傳操縱（Fly-by-Wire）。

A320，也是第一款真正把電傳飛控帶進主流民航客機的機型。

為了防止計算機出故障導致飛機失控，空客在A320里塞了五臺飛控計算機，分成兩個陣營：

ELAC（升降舵副翼計算機），共2臺，為主力。平時的俯仰和橫滾指令都歸它管。

SEC（擾流板升降舵計算機），共3臺，為替補。ELAC掛了，SEC頂上。

空客對共因失效（Common Cause Failure）的警惕是幾近到了病態的程度的，所謂的共因失效，就是兩臺機器因為用了同樣的芯片或是同一撥人寫的代碼，結果在同一個bug面前一起失了智。為了杜絕這種事，空客做了一個在當時看來極端的決定。ELAC交給法國宇航的團隊開發，跑在摩托羅拉68010處理器上。SEC交給Sfena和Thomson-CSF的團隊獨立編寫，跑在英特爾80186上。

圖4:A320 飛控系統不是一臺電腦說了算，而是一群互相監視、互相接管、也可能互相否定的計算機。

就這樣不同的兩撥人，不一樣的兩種芯片，兩套不同的代碼，還互相不通氣。

這種絕不允許兩臺機器長一樣的偏執不是憑空來的。

空客搞A300的時候，各歐盟成員國為了壯大本國的航空工業的實力，找了大量學術界的專家直接參與跟進研發，還允許他們把設計成果寫成學術論文發表。

結果就是，空客早期的很多系統設計可以看出來是帶著濃厚的學院派基因的，他們追求理論上的極致優雅，但是只要到了下一個機型，上一代的設計成品經常不能直接進行復用，必須要推倒重來過。

一位在亞太地區干了幾十年的資深機務跟我吐槽過：每上一個新機型的課，他們整個機務系都氣得牙癢癢——設計原理又變了，連工具都不通用，有點像早年的摩托羅拉手機，每個型號充電器都不一樣。

也正是這種每個新機型都敢從零開始的學院派基因，讓空客在飛控安全架構上走到了另一個極端。A320的異構冗余設計，就屬于是這個時代的產物。

但是這還僅僅只是外面的架構。

每臺計算機內部還一分為二：一路叫COM（Command，指令通道），負責真正計算舵面該偏多少度，把信號發給閥門；另一路叫MON（Monitor，監控通道），什么都不干，就負責盯著COM。

MON就是個監視者。它會獨立算一遍同樣的數據，然后和COM的結果進行比對。

如果對不上？不會去問原因，直接判定COM有問題，切斷輸出，控制權交給下一臺。之前我們拆A350剎車那篇文章的時候就專門聊過這套邏輯，這里不再展開。

但是要注意的是，COM/MON雙通道架構不只存在于飛控計算機里。

拿A320上霍尼韋爾提供的慣導系統（ADIRU）來說，在空客的官方手冊里我們是找不到它內部結構的，因為空客把它當成品件采購，系統文檔里只標接口和輸入輸出，里面怎么設計是霍尼韋爾的事。

但是如果翻開霍尼韋爾的設計資料，會發現內部同樣是雙處理器的COM/MON架構。一顆處理器負責對激光陀螺儀的原始數據做積分運算，另一顆在旁邊盯著。

兩邊算出來的結果對不上（比如高空宇宙射線打翻了某個比特位），這臺慣導就會直接把自己的輸出數據標記為"無效"，從總線上把自己摘出去，不讓污染的數據流到下游?？湛褪謨岳锝洺３霈F的慣導內部故障（IR Internal Fault），底層很大一部分就是這個COM/MON不一致觸發的。

從傳感器到計算機，從數據源到執行端，同一套哲學貫穿了整架飛機，這其中任何節點都不被完全信任，任何計算都必須有人盯著，只要一旦發現了分歧，寧可把自己關掉，也不允許帶著不確定性繼續往下跑。

好了，這里架構講完了。現在說這架ES-SAN號飛機身上那個隱藏了不知道多久的暗傷。

A320的水平安定面（尾部那塊可以整體調節角度的水平尾翼，用來做俯仰配平）通過一個叫THSA的作動器來驅動。THSA內部有一個超控機構（OVM），本質上是一組離合器和微動開關。

這架飛機的OVM，在之前某次維護中被涂抹了一種粘度偏高的潤滑油。

潤滑油只要一稠，離合器的摩擦力就忽大忽小，微動開關的行程也不夠了，會出現時靈時不靈的情況。

ELAC看到的情況就是配平手輪明明是在動的，但是OVM的開關卻是沒有觸發的。兩邊的信號對不上，ELAC讀不懂當前狀態，直接就報PITCH FAULT。

其實在出事之前的幾次飛行里，ELAC 1就已經反復觸發過這個故障警告了。機組當時沒當回事，也沒有去及時復位。

15時05分05秒，飛行教員在滑跑過程中手動轉動了配平手輪。OVM的開關又卡了。這次輪到ELAC 2也讀不懂配平狀態，兩臺ELAC先后宣布失效。

這下ELAC全退出了，但是飛機還沒有就此失控。飛控系統自動把控制權交給了SEC 2，控制從正常法則（Normal Law）降級為備用法則（Alternate Law），部分包線保護沒了，只是電傳系統還在兜底。

如果故事到這里就結束了，那么這只是一起普通的飛控降級事件，寫進內部安全簡報里就好了，不會有人多看一眼。

但別忘了，前面說的那次反彈，飛行教員沒預位擾流板，主起落架觸地后彈起來的那一下還在繼續。

三、1.02秒的臨界線

SEC接管俯仰控制之后，還有一件事要去操心，判斷飛機現在到底是在地面還是在空中。這個判斷對擾流板展開、著陸減速這些架構邏輯是至關重要的。

判斷依據來自起落架控制接口單元（LGCIU）。

圖5:起落架支柱壓縮還是伸展，決定系統眼里的飛機到底“在地上”還是“在天上”。

起落架的減震支柱被壓縮，LGCIU報告地面，支柱伸展開，卸載了，然后報告空中。

但是飛機落地的時候經常會彈一下，支柱一壓一彈，LGCIU的信號也會跟著跳。為了防止這種抖動把系統搞亂套了，空客在這套邏輯里還加了一道時間門檻：

減震支柱卸載持續超過1.02秒，才算真正離地，系統切入飛行模式。不到1.02秒的，當作彈跳噪聲，直接忽略掉。

而且只要切入飛行模式，系統會有一段鎖定期。哪怕飛機很快又落回跑道，支柱重新壓實，它也不會立刻切回到地面模式。

這條邏輯在絕大多數情況下工作沒什么破綻和瑕疵。正常彈跳通常也只有零點幾秒，遠遠夠不著1.02秒的門檻。

ES-SAN號的那次反彈，FDR（飛行數據記錄儀）記錄下來的支柱卸載時間剛好就在這個1秒區間的附近。但是FDR對這個參數的采樣精度比較有限，沒法精確到毫秒級。唯一能確定的是，它剛好 在 最敏感的1.02秒這個區間。

SEC計算機的COM通道和MON通道，他們各自內部有獨立的晶振（晶體振蕩器），時鐘是異步的（Asynchronous）。它們各跑各的，各自去讀LGCIU發來的數據。

COM讀本側LGCIU數據每120毫秒一輪，讀另一側每30毫秒一輪，MON的節奏和COM又有細微的差別。

平時差這幾毫秒根本沒人在意。但ES-SAN的那次反彈，支柱卸載時間剛好卡在1.02秒的邊界上。這幾毫秒的采樣偏差，就足以讓兩個通道讀到的數據產生分歧，COM那一輪采樣恰好采到了"超過1.02秒"，判定飛機離地，切入飛行模式；MON那一輪采樣采到的卻是"沒到1.02秒"，它還認為飛機在地面上。

同一臺SEC，在同一個瞬間COM說飛機在天上，MON說飛機在地上。

到了這一步都還沒出事，出事的是后續的一系列連鎖反應。

SEC在飛行模式和地面模式下，對升降舵用的是完全不同的控制律。

飛行模式下，飛行員拉桿請求的是G值變化，舵面偏多少度由計算機自己決定；地面模式下就非常簡單粗暴，桿量直接按比例映射舵面偏轉角。

同一個側桿輸入，兩套算法算出來的升降舵指令差距是巨大的。

MON通道一比對，發現COM的輸出和自己差了一大截。

它不會去琢磨為什么，邏輯里只有一種可能，COM那一路伺服閥指令失控了（Spool Valve Runaway）。

MON會二話不說，直接切斷SEC 2，控制權轉給SEC 1。

但SEC 1讀到的是同一對LGCIU發來的同一組數據，它內部的COM和MON在幾乎相同的時刻，經歷了完全相同的時鐘偏差和狀態分歧。

SEC 1的MON通道同樣判定COM損壞，也把自己切了出去。

兩部SEC在幾毫秒內接連發生離線。兩部ELAC早在此前已經退出，接管俯仰控制鏈路的SEC也被切了出去。

整條俯仰控制鏈路，一下變空了。

ECAM顯示器彈出警告：F/CTL L+R ELEV FAULT。

左右升降舵同時鎖死在0°中立位，側桿徹底失效。飛控系統掉到最底層的機械備份模式，PFD上亮起紅色的MAN PITCH TRIM ONLY。

從這一刻起，飛機的俯仰姿態完全取決于兩樣東西。

一是水平安定面（當時凍結在1.5°抬頭位置），以及發動機推力產生的力矩。

二是飛行教員只能靠配平手輪一圈一圈地搖，配合油門調姿態，在俯仰角一路飆升的劇烈上仰中把飛機穩住，最終落地。

四、流程殺死流程

現在回看整條鏈路：

OVM的一管潤滑油讓ELAC集體撂挑子，SEC被迫接管，然后一次1秒鐘的彈跳恰好卡在1.02秒的臨界線上，讓COM和MON對飛機狀態各說各話。

沒有任何硬件損壞，沒有任何代碼bug。每一臺計算機在切斷自己的那一刻，都在嚴格執行設計者寫給它的保護邏輯。

站在MON的角度看，關掉COM沒有錯。伺服閥指令真要是失控了，不關掉飛機就完了。

但是MON沒有能力去分辨COM是真壞了還是我們倆看到的世界不一樣。對MON來說，這兩種情況長得一模一樣。

寫分布式系統的人對這個場景應該不陌生。

圖6:航空飛控和分布式系統有一個共同的噩夢：沒有全局時鐘，各自都認為自己看見了真相。

兩個節點各自有自己的時鐘，從同一個數據源采樣，卻在同一個臨界閾值面前做出了相反的判斷。

狀態不一致，競態條件（Race Condition）觸發，然后腦裂（Split-Brain），節點互相切斷，整個集群雪崩式垮掉。

工程師們后來發明Paxos、Raft這些共識協議，本質上就是為了盡量避免這類事情，在做決定之前，先確認大家看到的是同一片天空。

空客的COM/MON架構沒有這個機制。MON不會去和COM打商量，前面說了，它只負責監視。

物理世界在1.02秒的邊界上給了一個模糊信號，兩個通道各自為政，各自得出自己的結論，MON拿著自己那個結論，直接斷掉了COM的輸出。

圖7:這起事故最冷的地方在于：真正觸發連鎖反應的，不是猛烈撞擊，而是一次卡在時間門檻上的短暫反彈。

這件事就算放到組織管理里也是一樣。

我們想象一家公司，業務部門相當于COM，審計部門相當于MON。

一線只要出了狀況，兩邊同時收到了現場報告，但一般信息傳遞有幾個小時的時差。業務部門看著早上的數據，覺得事態升級了，需要馬上拉響應急；審計部門看到的是中午的數據，覺得只是正常波動，根本不用動。兩邊結論完全相反。審計部門會先問一句我們看的是不是同一版數據嗎？

不會。它只會按流程走，業務部門的動作和事實對不上，判定業務失控。

于是熔斷，凍結，審批暫停。

期間沒有人違規，也沒人拍腦袋去決定，所有的表格還都填對了。

最終結果卻是業務停了。

萬萬沒想到干掉業務的，是流程本身。

空客在1.02秒的邊界上踩到的坑，其實和所有大型組織面對的困境是一回事。我們設計的每一道安全流程，在它被觸發的那個瞬間，往往都是對的。但當好幾道流程在同一個模糊事件面前各自做出判斷、互相否定的時候，正確的流程疊加在一起，反而會把整個系統給限制住了。

空客后來專門針對這個問題做了修復，思路也不繞彎子，讓COM和MON在判斷起落架地空狀態時，走同一套判定邏輯、用同一個時鐘基準，從根子上去消除兩邊因采樣偏差而產生分歧的可能。

但有些補丁雖然能修復代碼，卻修不了也改變不了這件事真正暴露出的問題。這架飛機上最危險的東西，從頭到尾都不是那管涂錯的潤滑油，也不是那次一秒鐘的彈跳。是那五臺計算機之間的那套精密的監控機制。

流程越多越安全？

當保護流程開始互相否定的時候，復雜性本身就是最大的單點故障。

這里是「飛機的賬本」，我們下期繼續拆解分析那些看起來很安全、實際上卻很要命的設計。