前阵子小白总结了某飞机反推手柄拉不动的故障(有兴趣的小伙伴可以阅读:737NG 反推手柄拉不动),没想到不到一周就用到总结的知识了,而且通过分析本次故障信息的底层逻辑,小白发现了一种快速判断故障的方法。 (点击图片可以放大查阅)(点击图片可以放大查阅)根据FIM,右发放出型信息S832可能的故障原因如下: 如果按照FIM逐步隔离,有5个可能的故障因素。小白发现通过SSM 78-36-22分析S832信息的故障逻辑并结合故障现象可以快速判断最可能的部件是右发右侧同步锁。 推理过程如下👇👇👇 推理判断故障件 下面从两个维度进行推理:故障现象及S832信息底层逻辑。 一、故障现象层面推理 根据“译码显示右发左侧反推正常放出”现象得出如下结论:
我们知道右发两侧反推作动器共用同一个CVM、两侧的同步锁供电控制均通过S4电门及R479。既然左侧反推工作正常,说明左侧和右侧共用的部件工作正常,问题只能出在右侧反推相关部件,最可能的原因是同步锁没有解锁(涉及同步锁本体及分支线路)或锁作动器没有解锁。 通常情况下,右侧锁作动器没有正常解锁会触发放出型信息S836,但本次故障只有S832信息,可以推测锁作动器正常解锁。 至此,经过上述推理分析,故障源就锁定在同步锁或同步锁上游相关线路了。 根据上述现象判断故障源需要数据支持和一定的经验,有人会问如果第一次遇到这类故障是否也可以快速得出结论?还有人会问如果同步锁没工作为什么没有故障信息? 其实通过分析S832信息的底层逻辑,即使没有经验和译码数据支持,也能判断故障件是同步锁,并且可以理解为什么同步锁故障却没有故障信息。 接下来从故障逻辑层面寻找上述问题的答案👇👇👇 1、放出型信息S832触发逻辑 分析SSM 78-36-22,右发放出型信息S832的触发需要与门A输出逻辑信号1且保持0.3S以上。 注:下述条件需同时满足
(点击图片可以放大查阅)
(点击图片可以放大查阅)我们先分析RIGHT T/R SLEEVE LOCK SENSOR。 从下图中不难看出与门A和与门D有一个共同的输入是与门B,因为已经有S832信息,说明与门B的输出必为1。那么与门D的最终输出就是由RIGHT T/R SLEEVE LOCK SENSOR决定,同样,如果我们知道了与门D的输出,也可以倒推RIGHT T/R SLEEVE LOCK SENSOR的输入是多少。 因为本次故障无放出型S836信息(R SLEEVE LOCK SENSOR),所以D门的输出必为0。因与门B已经给出输入1,若要D输出0,另一路给D的输入必为0。这里需要注意另一路的输入是非门,因此非门上游给出的是逻辑信号应为1,即RIGHT T/R SLEEVE LOCK SENSOR给出的逻辑信号为1,即SENSOR为NOT LOCKED状态。 (点击图片可以放大查阅)
正常情况下,反推放出的大致流程是反推手柄拉起至连锁位👉同步锁解锁👉CVM内部活门作动让系统压力通过后到达反推作动器👉上锁作动器解锁👉反推放出👉双侧反推放出至60%后,连锁结构解锁,反推手柄继续后拉获得更大反推力 通过逻辑分析我们知道CVM正常工作且两侧上锁作动器均正常解锁,那么S832背后的原因要么是右发反推真的没有放出来,要么是RIGHT T/R SLEEVE STOW SENSOR给了错误指示。 通过下图标记的两个时间5S和0.3S就可以排除STOW SENSOR指示的问题。因为从EAU接收到S832成立的逻辑到最终判定故障有5.3S左右的持续时间,这期间足以让反推从STOW位放出至60%的位置,如果反推到60%以上,反推手柄就不会卡在连锁位无法拉动。也就是说, 本次若是STOW SENSOR导致的指示故障,虽然也会有S832信息,但是不会让反推手柄卡在连锁位。 (点击图片可以放大查阅)到这里我们通过逻辑分析判断最可能的故障件就是同步锁。 下面分析为什么同步锁故障却没有故障信息👇👇👇 同步锁信息的触发逻辑 分析SSM 78-36-22,同步锁是否解锁的逻辑输入来自pin18和pin30。 (点击图片可以放大查阅)进入SSM78-32-61,可以看到pin18/pin30的上游输入来自R479,但是逻辑输入线路和同步锁供电线路并非是同一路,也就是说,只要pin18/pin30接收到供电,EAU就认为同步锁收到解锁电压了,即使同步锁本体故障或者本体没有收到供电也不会触发同步锁信息。 (点击图片可以放大查阅)排故结论及故障现象还原 如果EAU故障信息只有放出型信息S831或只有放出型信息S832,优先核实反推手柄是否拉出一点就放不出来(也可以通过DU REV指示或者译码数据看反推是否放出进行判断),如果手柄拉不动,优先隔离对应侧的同步锁。如果手柄可以拉动或者反推放出,就重点看对应侧的SLEEVE STOW SENSOR和靶标,从指示层面隔离。 注:由于反推故障信息背后的影响因素非常多,上述建议小白暂时不对首次故障进行应用(因为还需要对多个数据样本分析去验证上述结论),主要应用于类似本次案例故障二次出现且故障信息稳定的故障。 结语 深挖EAU故障信息底层逻辑,能够获取额外线索,有些线索是FIM中没有提到的,如果再结合故障现象和译码数据,可以快速锁定故障部件,大大提高排故效率。 |
|