[22自动飞行] 案例分享 ｜ 自动驾驶脱开时无音响警告

全世界只有不到1 % 的人关注了九品机务

你真是个特别的人 

2023年1月，一架737NG飞机三亚过站机组反馈进近阶段脱开自动驾驶时无音响警告铃音，且ASA的A/P红灯不亮，地面DFCS自检当前正常，无历史代码，音响警告组件BITE自检正常，ASA测试正常，沟通机组正常放行飞机，后续航班中武汉过站机组又反馈脱开自动驾驶时无音响警告铃音，但ASA的A/P灯光正常点亮。

南宁航后进行DFCS BITE LIBRARY TEST中的脱开警告测试过程中，无自动驾驶脱开音响警告，ASA中A/P灯光指示正常，后续又执行了两次脱开警告测试，均无自动驾驶脱开音响警告，有自检代码22-11283 A/P WARN HORN FAIL，可能故障的部件为音响警告组件AWM。

但经过对SSM的分析，判断MCP故障的可能性更大，所以更换了MCP，后续执行脱开警告测试过程中自动驾驶脱开音响警告工作正常，且后续航班运行中音响警告功能均正常。

音响警告系统为机组提供飞机异常或不安全情况下的音响警戒，包括以下几种情况：

• 不安全着陆构型

• 不安全起飞构型

• 客舱释压

• 自动驾驶脱开

• 超速

• 着火

• 机组呼叫

• 选择呼叫

音响警告系统主要部件为音响警告组件AWM，位于驾驶舱副驾侧脚蹬左侧，内部有两个完全相同的通道，且两个通道同时接收并处理数据，如果一个通道失效，音响警告的输出将减少6分贝。

关于音响警告系统的更多内容，详见之前的文章——音响警告组件单通道失效能放行吗？

通过系统图可以发现，由于供电及接地线路的不同，导致不同条件触发的音响警告铃音的区别，更具体的内容可参考音响警告组件的CMM。

AWM的BITE测试很简单，只需要一把一字螺刀~

但是，AWM作为终端部件，即便BITE测试正常，也不能证明所有音响警告系统功能完好。

当日机组反馈故障时，为验证AWM的功能，进行了AWM BITE测试，同时验证了火警警告、超速警告、起飞警告、机组呼叫等功能。但后来回想起来发现，这些测试工作可以说是必要但不充分的。

如前所述，由于供电及接地线路的不同，导致不同条件触发的音响警告铃音的区别，我们可以理解为各个音响警告系统之间为并联关系，某个系统的音响警告功能正常与否并不影响其他系统的音响警告功能。

机组反馈的故障为自动驾驶脱开时无音响警告铃音，其实我们只需根据FIM进行一个DFCS BITE LIBRARY TEST中的脱开警告测试，这个测试是再现一个自动驾驶脱开的过程，与飞行中应该有的现象是一致的。当然，如果为间歇性故障，测试过程也不一定能够发现问题。但这个测试内容才是首先且必须要进行的。PS：FIM中的初始评估内容往往是最容易验证故障且最正确的排故方向。

当自动驾驶脱开时，由MCP内部的衔接内锁逻辑电路触发脱开程序，并触发AWM及ASA的电门接地，从而发出音响警告，点亮A/P红灯。

由于第一次机组反馈自动驾驶脱开时无音响警告及ASA灯光提醒，可以大致判断MCP内部触发逻辑电路异常，第二次机组反馈自动驾驶脱开时仅无音响警告，可以怀疑MCP内部触发音响警告的电门故障或音响警告组件故障。综合两次的故障现象及线路图分析，判断MCP故障概率更大。

而在进行DFCS BITE LIBRARY TEST的脱开警告测试过程中无音响警告，且可能故障部件为AWM，但是故障代码指向的FIM中，依然把MCP列为最可能的故障部件。

综合以上分析判断，MCP故障可能性最大，更换后测试正常，且后续飞机状态均正常。

故障排除后不免产生一些疑问：

1、DFCS BITE当前状态快速测试通过能够证明DFCS系统是好的吗？什么情况下才适用？

2、DFCS BITE测试结果中提到的可能故障部件准确率？这让我不得不想到之前的一次排故经历——别让代码蒙蔽了双眼

3、AMM中关于更换AWM后需要进行AWM BITE测试，然后需要通过前推油门杆来验证起飞警告，这一步骤是否有必要或者是否足够全面？