A330机型“BRAKE RELEASE”故障处置背后的细节与思量

某次航班，当飞机以自身动力滑出后，ECAM跳出告警：BRAKE RELEASED（部分A330机型地面会自动抑制此故障），除了琥珀色标题“BRAKE 8 RELEASED”外没有任何内容和动作。查询MMEL参引，放行条件中包含两个参考项目（如图1）。

图1

继续查询这两个参考项目的内容会发现：

对于“32-42-01 Main/Centerline Wheel Brake”，涉及O项及M项；

而对于“32-42-05 Tachometer”，仅涉及O项。

既然两种情况都可能导致“刹车松开”故障，我们在此刻能否判明是哪一种？

标准的流程当然是机务通过MCDU CMS中MAINTENANCE MENU目录下的SYSTEM REPORT来进行测试，从而得出结论。而机务不在场的情况下，飞行员则可以联系公司地面部门咨询，当前故障将通过飞机ACARS上传至公司平台，机务通过查看报文中的相关信息可以从远程帮助机组判别故障背后的机理。

在此例中，如果机务告知机组，报文中显示为Tachometer(转速表)故障，那么在仅涉及O项的情况下，机组也许可以避免一次滑回所造成的航班延误。可当我们翻开这一故障O项时，会发现似乎并没有那么简单。

在MMEL中查询Tachometer(转速表)，除涉及本身O项外，还需参考32-42-04 AUTO/BRK Function内容，这部分理解起来很简单：最大着陆能力为CAT III SINGLE，还有滑行期间忽略T.O MEMO中的AUTO BRK…MAX，本文对此不再赘述。

我们重点说一下转速表自身的O项内容，它分为两个时段（如图2所示）：

图2

在“飞行准备/限制”时段中，说明了这个故障有性能损耗，其等同于刹车不工作的性能损耗，需要继续参考32-42-01A 中主/中央轮刹车(一个刹车失效)。这种“套娃式” 的查询方式会使飞行员产生焦虑心态，如果还有运行时间的要求，压力也将倍增。

“在地面”时段，则提醒我们即便在办理保留之后，此故障也可能重现，可以忽略这个警报。由于在80kt后，此故障才会被抑制，所以机组需要在起飞滑跑时做好相关预案。

我们继续翻开第一个时段中提及的32-42-01A，整整一页操作内容映入眼帘（如图3所示）。

图3

这个操作程序直接分为了五个时段，其中包含了性能查询，刹车不平衡，起飞后延迟收起落架程序等内容。我们注意到，这五个时段中，第一个时段的标题恰恰也是“飞行准备/限制”。那么问题来了，在轮速表的O项中，仅在第一个时段提及到应参考32-42-01A，那么是参考其对应的这第一个时段内容（性能补偿），还是参考整个程序呢？

所幸现在有大量时间来讨论这件事，而不是坐在运转着发动机的飞机上急于寻求结论。还记得吗？32-42-01A也刚好是“刹车松开”故障第一条参考项目“Main/Centerline Wheel Brake”中失去单刹车情况下的O项程序。回溯到之前的场景，当故障跳出时，机组联系机务，机务通过远程监控，如果发现报文中确实是主轮刹车故障而非轮速表，那么涉及M项，机组需要滑回飞机进行排故，在机务完成M项并保留“32-42-01A One inoperative”后，机组执行此O项操作程序并继续运行。

那么想解决之前的疑问，我们就需要先着眼于这两种保留项目之间的区别，对于“32-42-01 Main/Centerline Wheel Brake”，触发警报的机制是由于机轮上的伺服活门卡阻在关闭位，从而阻断了液压的供给（如图4）。这种情况下，机务的M项工作是在刹车松开的状态下，将刹车毂的绿系统和蓝系统的液压快卸接头脱开，以确保此轮的正常刹车和备用刹车失效

图4

由于BSCU在此状况下已无法再控制刹车，起飞后机组应保持起落架放下2分钟，如果起飞后立即收起起落架可能会感受到振动。同时，机组操作时也需要监控速度以防止收起落架超速。

对于“32-42-05 Tachometer轮速表”，一般来说BSCU对比轮速和空速，通过伺服活门控制刹车。当轮速表故障时，BSCU接受不到信号，为保证轮胎不会出现抱死状态而选择直接松开刹车，此时自动刹车也会因为在计算伺服活门指令时发生错误从而导致失效。当起飞后，机组将起落架手柄至于UP位，BSCU依然可以控制伺服活门，通过绿液压来刹停机轮，这期间并不需要转速表的反馈。

从以上的逻辑我们就可以推断出，执行轮速表保留的O项，只需参考主轮刹车失效O项中的“飞行准备/限制”内容，即性能损耗部分，而不必参考后续时段的内容。空客公司在我方咨询后也给出相同的答复：

由此看来，小标题名称相同并非巧合，而是空客有意为之。

在解决了参考项带来的困惑后，我们终于可以明确的执行O项了，首先第一句：“确定与OCTOPUS程序相关飞行手册性能消耗”，什么是OCTOPUS？如何确定？

OCTOPUS（Operational and Certified Take Off and Landing Performance Universal Software）是PEP以及Flysmart软件背后的基础数据。

事实上在2021年公司MEL中，在此处的O项中还包含查询表格，以及繁冗的计算提示。由于机组在短时间内无法通透地理解大篇的性能描述和注意事项，机队甚至建议，即便是轮速表保留只有O项，机组也可以滑回以便向性能部门寻求协助，性能部门则通过PEP重新制作起飞性能表格，来代替O项中复杂的性能计算。然而这一切，随着Flysmart的到来而改变，机组可以通过点击，在FS轻而易举地计算出更加精准的起飞性能，从而避免滑回及航班延误带来的无奈。

我们先来看“32-42-01 主/中央轮刹车”这一项目，“飞行准备/限制”时段，注释中说得很明确，只需查询“BRAKES CONFIGURATION-1 BRAKE INOPERATIVE”，从FS的MEL标签中找到对应选项即可（如图5）。

图5

接下来是“32-42-05 轮速表”，既然性能损耗等同于一个刹车失效，我们还拿上面这个条件查行不行？可偏偏MEL标签下还有一个专门针对”轮速表“的选项（如图6）。

图6

照道理，我们保留了轮速表就应该选择轮速表，那么又如何理解O项里提到的参照另一O项内容呢？上面的Brakes configuration还点不点？困惑再次出现，空客对此给了明确的解释：只查询“轮速表”就可以了，其自动包含了失去一个刹车的性能损耗。实际验证中也能表明，无论选哪个选项，查询的结果都相同，这正对应了MMEL中描述的二者性能损耗等同，无需两个选项同时选择计算。

顺便一提，如果在巡航到落地过程中出现“刹车松开“警报，在状态页面也会提示机组查询落地性能，这时在FS中如何选择呢？其实更加简单，因为这时候我们选择的并非是MEL标签，而是ECAM标签，在这个标签下，所有机轮的刹车松开一目了然，点选即可（如图7）。

图7

我们再来讨论另一种情况，比如航班落地前出现了“刹车松开”故障，落地后机组填写了TLB。机务在过站中重置了BSCU电门，故障消失且测试正常而没有进行保留，只是告知机组，如果在下段滑行中再次出现此故障，可以重置BSCU电门。

然而，在A330的《QRH》系统重置表中，并不包含“刹车松开”这一故障，有了机务这句话，我们是否相当于有了一面”免死金牌“，随时故障随时重置，万事大吉呢？答案是否定的。

一方面，只有采取适当的排除故障措施，才能降低潜在的风险。在此例中，虽然重置BSCU可以短暂地消除轮速表故障，但这也只能理解为是在快速过站情况下，保障运行的一种手段，其本质上并不能解决源头问题，且有很大概率在下段运行中再次触发故障。重复地重置，将分散机组滑行当中的注意力，其触发时机也会影响机组关键节点的判断力，对此，机组应有足够的心理准备及相关预案，而不应忽视此类问题。

另一方面，这种重置仅限于地面，如果由于“惯性思维“，在进近过程中跳出刹车松开故障仍然重置BSCU，将给飞机带来极大的危险。在之前的几起案例中，正是由于轮速表故障，机组空中重置BSCU后，导致BSCU错误地认为实际机轮速度为0kt。15秒后，制动功能以设定的减速速度恢复，BSCU在此时却无法测算防滞顺序，而将全液压送向刹车，从而导致机轮爆胎。 

只有透彻地理解故障，才能在面对故障时不再茫然和盲目，考虑”安全底线“的同时，更能兼顾”运行能力“，这同样也是我们飞行员责任心的一种体现。笔者以简单的刹车系统故障为引，探讨其处置背后的思考与逻辑。安全运行不是一个人的事情，飞行员也非孤军奋战，我们应运用好当前的资源和条件，在平时和地面及机务人员多沟通多探讨，在技术不断革新的当下，坚持与时俱进，这同样是我辈所必需的精神。