之前，我将机队中典型的起落架收放故障做了一个汇总：《737NG 起落架相关故障汇总》。其中，付费内容有一个案例是关于前起落架放出慢的分析，和这个案例似乎有点类似。那个案例最终发现是活门总管组件内的一个释压活门打开压力变小，前起落架放出油路的部分液压被旁通从而导致了前起放出耗时较长。然而，时隔大半年之后，该飞机又反映了同样的故障现象，后来发现是前起收放作动筒内部的封严破损严重，内漏导致放出变慢。但这回的故障又很特别，这架飞机的故障现象是3个起落架都慢（同步），且只出现在收上阶段。自检PSEU当前并无故障信息，历史有：32-64001 INTERNAL FAULT，32-62002 TRA R LT 44 FAULT信息。先后更换了PSEU、起落架控制手柄组件、起落架转换活门、起落架选择活门，可故障依旧间歇性出现，最终更换M1767后正常。开始分析前，我们首先回顾一下起落架红灯点亮的逻辑：1、手柄在DOWN位，起落架未放下锁定；
2、手柄在UP或OFF位，起落架未收上锁定；
3、任意油门杆角度小于44°且无线电高度低于800英尺，或起落架手柄在DOWN位，且起落架未放下锁定。![]()
图1. 左主起红灯点亮逻辑
简单的说，红灯点亮的逻辑就是手柄和起落架实际位置不一致，或着陆形态下起落架未放下锁定的构型警告。通过对过去多个航段数据译码，发现起落架收上慢这一现象并不稳定，而是间歇性出现的：图2. 68个航段收放时间曲线
图2曲线/图3表格是我用python遍历了68个航段的数据，统计三个起落架红灯参数=“WARNING”的帧数得出的结果。如果靠人工去打开每个csv文档挨个数，那就太累了，实现代码在下面我会分享。
图3. 部分航段的收放时间数据
由于三个起落架都同时收上变慢，借鉴之前前起落架放出慢的案例经验，如果液压部件内漏是故障源，可以判断故障的源头应该在上游的公共端：起落架转换活门、起落架选择活门或起落架收放控制机构（手柄组件、钢索、滚轮、扇形盘）。但假如是液压部件内漏引起的，必然是有趋势性的且是不可逆的！不会出现一会儿慢一会儿又正常的情况。而且在故障航段，虽然红灯指示转换很慢，但从液压油量的变化来看，起落架实际上已经完成收上锁定了。图4. 故障航段的译码数据
如图4所示，6:35:35时刻起落架手柄收上，红灯点亮，此时A系统液压油量约为103夸脱。9秒后，6:35:44，液压油量已经到了83夸脱左右，说明此时起落架已经收上到位了（3个起落架的收放作动筒伸出通常所需的液压油量约为20夸脱）。然而，直到6:35:55时刻红灯才熄灭。从6:35:44到6:35:55这个时间段内，三个起落架到底经历了什么呢？起落架收放液压油路如下图5/6所示：当提起起落架手柄，后部的推拉钢索通过齿轮盒、钢索、扇形盘驱动选择活门内部的滑阀移动到UP位。A系统的压力就会经过旁通活门给到三个起落架的传压筒、锁作动器、收放作动筒，完成起落架收上控制。图5. SSM32-30-00前起
图6. SSM32-30-00主起
假如起落架收上钢索LGVA张力不足导致手柄UP位时应钢索传动行程不够，选择活门的开度不足，使得供往收放作动筒的液压流量减少。那么在正常与不正常之间，应该还会有一些中间过渡的数值，比如10秒、11秒、12秒、13秒……可这飞机的起落架收上时间也太两极化了：要么正常（小于9s），要么时间很长。很不符合真实收上慢的物理规律呀！当然，是否是真实的收上慢，可以在地面顶升后用液压车收放模拟出来，只要观察前起舱门即可。可受限于很多客观条件，其实也并不好执行。重新复盘了一遍译码数据后，我们发现了一个重要的规律：故障航段的起落架红灯熄灭的高度普遍约在800FT左右（下图中，右侧三列的ALTRAD1参数，我采集的是红灯熄灭前最后一帧对应的无线电高度）。而正常航段，红灯熄灭的高度一般都在200~350FT之间。下图第二行黄色高亮数据是QAR的一些无效干扰数据导致的统计错误，忽略就行了。
图7
下面是我用编程的方式批量读取数据实现统计的思路：
# 读取CSV文件，跳过前4行作为header
df = pd.read_csv(file_path, header=4, encoding='gb18030')
# 剔除开头和末尾的一些无效数据
df['ENG1N2'] = pd.to_numeric(df['ENG1N2'], errors='coerce')
df = df[(df.ENG1N2>60) & (df.ENG1N2<102)]
# 筛选爬升阶段的数据
df1 = df[(df.FLIGHT_PHASE == 'INIT CLIMB')| (df.FLIGHT_PHASE == 'CRUISE')| (df.FLIGHT_PHASE == 'LVL CHANGE')]
left_gear_bool = (df1['GEAR_WAR1'] == 'WARNING')
right_gear_bool = (df1['GEAR_WAR2'] == 'WARNING')
nose_gear_bool = (df1['GEAR_NOS_WAR'] == 'WARNING')
# 找到最后一行WARNING对应的ALTRAD1值
if left_gear_bool.any():
letfgear_up_altrad1.append(df1[left_gear_bool].iloc[-1]['ALTRAD1'])
else:
letfgear_up_altrad1.append(None)
if right_gear_bool.any():
rightgear_up_altrad1.append(df1[right_gear_bool].iloc[-1]['ALTRAD1'])
else:
rightgear_up_altrad1.append(None)
if nose_gear_bool.any():
nosegear_up_altrad1.append(df1[nose_gear_bool].iloc[-1]['ALTRAD1'])
else:
nosegear_up_altrad1.append(None)
letfgear_up.append(left_gear_bool.sum())
rightgear_up.append(right_gear_bool.sum())
nosegear_up.append(nose_gear_bool.sum())
真相已经呼之欲出：红灯亮是因为M1766/M1767给出了错误的油门杆角度信号，导致在RA低于800FT时将手柄放到UP位后，满足了PSEU内的起落架构型警告的触发条件，红灯就会一直保持点亮，直到RA＞800FT。以左主起落架为例，红灯点亮逻辑如图8所示：![]()
图8. SSM32-61-11
进近阶段收油门后，RA跳变导致3个起落架红灯亮的案例很常见，一般都伴随着间歇性的音响警告。可为什么这架飞机却只有红灯点亮却没有音响警告呢？![]()
图9. SSM32-61-21 SHEET3
结合SSM32-61-21的SHEET1和SHEET3其实可以得出答案。线路图中的旗标2注释：A ground on any input equals a logic "True"。翻译过来就是，任何输入端接地等于逻辑“真”。即，接地相当于输出1。如果只是图10中M1767内的S1电门故障，输出了Retract的真信号，下图中的或门G并不会输出着陆进近推力的激活信号。那么图9中的蓝色激活信号将不成立，AWM也就不会发出音响警告了。![]()
图10. SSM32-61-21 SHEET1
其实故障最开始时，PSEU历史曾记录过32-62002 TRA R LT 44 FAULT故障信息。该信息的触发逻辑是：S1处于TRA<44°的位置，同时S8处于TRA＞53°，S9处于TRA＞64°的位置。信息已经很明确指向是自动油门电门组件了。图11. 自动油门电门组件内S1/S8/S9功能
综上，起飞阶段3个起落架红灯转换慢是由于M1767内的S1电门触点故障导致的。该触点间歇性故障触发了着陆形态下的起落架构型警告，但只要S8电门触点正常，就不会有音响警告。
感谢大家对机务论坛的支持，关注机务论坛，倾听机务心声！航企优秀的方面必定宣传，不足的地方也必须指出，让领导们重视问题，解决问题，营造更好的机务维修环境。同时，征集劳动仲裁案例，分享案例，让更多的小伙伴能了解劳动纠纷的解决方式，通过劳动仲裁维护自己的合法权益。
![]()
