之前有不少粉丝留言催我写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架构。一颗处理器负责对激光陀螺仪的原始数据做积分运算，另一颗在旁边盯着。
两边算出来的结果对不上（比如高空宇宙射线打翻了某个比特位），这台惯导就会直接把自己的输出数据标记为\"无效\"，从总线上把自己摘出去，不让污染的数据流到下游。空客手册里经常出现的惯导内部故障（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在判断起落架地空状态时，走同一套判定逻辑、用同一个时钟基准，从根子上去消除两边因采样偏差而产生分歧的可能。
但有些补丁虽然能修复代码，却修不了也改变不了这件事真正暴露出的问题。这架飞机上最危险的东西，从头到尾都不是那管涂错的润滑油，也不是那次一秒钟的弹跳。是那五台计算机之间的那套精密的监控机制。
流程越多越安全？
当保护流程开始互相否定的时候，复杂性本身就是最大的单点故障。
这里是「飞机的账本」，我们下期继续拆解分析那些看起来很安全、实际上却很要命的设计。
胜亿配资提示：文章来自网络，不代表本站观点。
