轨道交通预测性维护：走行部与弓网系统监测，从青岛动车检修厂的现场说起
2024年Q2，我去了趟青岛，去拜访一家专门做动车组高级修（也就是大家说的"四修五修"）的检修公司。在他们的检修车间里，我第一次看到那种"红房子"里的复杂------一辆八编组的动车被大卸八块，工人在转向架下面钻进钻出。
跟他们的总工聊了一上午，最大的感触是：轨道交通的预测性维护，跟制造业完全不是一个量级的复杂度。
一辆CR400AF动车组有数以万计的传感点（光是轴箱轴承就32个，每个带振动+温度），加上弓网、受电弓、视频监控......维护窗口又是"天窗期"（夜里11点到凌晨4点），根本不可能像工厂那样随时停机拆东西。
这篇文章，我就把那次聊天里学到的、加上我这两年在轨道交通领域做的一些项目，攒成一套相对系统的思路。
走行部和弓网：两个独立的子系统
很多人会把"动车预测性维护"当成一个整体来看，其实完全是两套体系：
走行部（车辆的"腿"）： - 监测对象：轴箱轴承、齿轮箱、牵引电机、轮对、制动夹钳 - 监测方法：振动、温度、转速、加速度 - 故障模式：轴承剥离、齿轮点蚀、踏面擦伤、制动抱死 - 数据特点：高频振动数据为主，采样频率往往5kHz以上
弓网系统（车辆的"嘴"）： - 监测对象：受电弓碳滑板、接触网导线、定位器、支撑装置 - 监测方法：接触压力、拉出值、燃弧、图像 - 故障模式：碳滑板磨耗、导线硬点、受电弓羊角变形 - 数据特点：动态接触力和图像视频为主，时间分辨率ms级
这两个子系统的传感器、数据链路、算法模型都是独立的。下文分别展开。
走行部监测：传感器怎么布置
我先说走行部，因为这是预测性维护在轨道交通里最成熟的部分。
一辆动车有4个转向架，每转向架2根轴，每轴2个轴箱，每个轴箱至少1个轴承。所以一台8编组动车，光是轴箱轴承就 8 × 4 = 32个，每个都需要1~2个振动传感器，温度传感器再加1个。
传感器布置有两种主流方案：
方案A：轴箱内置式 - 传感器集成在轴箱轴承的外圈端盖上 - 优点：信号质量高，不受安装位置影响 - 缺点：成本高，单个传感器1万元以上；更换时需要拆轴箱，影响检修周期
方案B：轴箱外置式（更主流） - 振动传感器通过螺纹固定在轴箱端盖外侧 - 优点：成本低（单个2~3千元），更换方便 - 缺点：受轴箱体结构的影响，需要做传递函数补偿
国内主流的方案是B，配PCB 356A32这种ICP加速度传感器，配装磁座固定。
齿轮箱和牵引电机的监测配置类似，下面我贴一段Python代码，是走行部数据预处理的核心模块。这段代码可以用在我之前参与的某个地铁项目的振动采集卡配置：
python
import numpy as np
from scipy.signal import sosfiltfilt, butter
from dataclasses import dataclass
@dataclass
class AxleboxConfig:
"""轴箱轴承监测配置"""
sensor_id: str # 传感器ID
sample_rate: int = 5120 # 采样率 Hz
bearing_model: str = 'FAG NJ2232' # 轴承型号
axle_diameter_mm: float = 130 # 轴径
bearing_pitch_diameter_mm: float = 178.5
ball_diameter_mm: float = 28.75
num_balls: int = 17 # 滚子数
@property
def char_frequencies(self):
"""
计算轴承四特征频率（单位：转速的倍数）
BPFO: 外圈通过频率
BPFI: 内圈通过频率
BSF: 滚子自转频率
FTF: 保持架频率
"""
d = self.ball_diameter_mm
D = self.bearing_pitch_diameter_mm
n = self.num_balls
# 简化的轴承几何公式（外圈固定，内圈旋转）
# d/D < 0.5 才近似准确
if d/D > 0.5:
raise ValueError("滚子直径太大，几何公式不适用")
bpfo = (n / 2) * (1 - d/D) # 倍数，需乘以转速才是Hz
bpfi = (n / 2) * (1 + d/D)
bsf = (D / (2*d)) * (1 - (d/D)**2)
ftf = 0.5 * (1 - d/D)
return {
'BPFO': bpfo,
'BPFI': bpfi,
'BSF': bsf,
'FTF': ftf,
}
@property
def fault_freqs_at_speed(self, rpm: float):
"""给定转速，计算实际特征频率 (Hz)"""
shaft_freq = rpm / 60
chars = self.char_frequencies
return {k: v * shaft_freq for k, v in chars.items()}
# 使用示例：CR400AF 动车组轴箱
axle = AxleboxConfig(
sensor_id='J1-AX01-TEMP',
sample_rate=5120,
)
print("轴承特征频率（倍数）:", axle.char_frequencies)
# 250 km/h 对应轮对转速约 1480 rpm
faults = axle.fault_freqs_at_speed(1480)
for k, v in faults.items():
print(f" {k} = {v:.2f} Hz")注意这里有个细节 ：轴承的特征频率是转速的倍数 ，不是绝对频率。所以做频谱分析的时候，一定要做阶次分析（order tracking），把频谱归一化到转速上。否则速度一变化，特征频率就跑掉了。
弓网监测：另一个维度的挑战
说完走行部，再聊弓网。
弓网这个东西，说实话，我当时在青岛看到实物的时候挺震撼的------动车顶上那个"L"形的受电弓，跟架空接触线接触的瞬间压力、拉出值都在毫秒级变化，还要保证接触可靠不产生燃弧。
弓网监测的核心是接触压力 和拉出值。给你看几个真实的数据：
| 监测项 | 正常范围 | 异常阈值 | 影响 |
|---|---|---|---|
| 接触压力 | 70~120 N | <60N 或 >150N | 离线/拉弧 |
| 拉出值（水平偏移） | ±300mm | >400mm | 刮弓/挂线 |
| 燃弧次数 | <5次/公里 | >10次/公里 | 滑板灼伤 |
| 接触线高度 | 5000~6500mm | <4900mm | 离线 |
弓网监测的难点是接触压力传感器必须装在受电弓滑板上，那个地方是高压、振动、雨水、冰雪、温差、电磁干扰全占齐了。我之前参与的一个项目是济南局集团的，整个弓网检测系统装在车顶箱里，光电磁屏蔽就折腾了三个月。
弓网监测里有个特别有意思的算法------图像识别碳滑板磨耗。你可能想不到，原来磨耗测量以前都是用塞尺人工量的，1个滑板测8个点，每列车8节车厢，64次测量，1个工人至少1小时。现在用线扫描相机+深度学习模型，5秒搞定。
注意这里有个细节 ：碳滑板的磨耗不是一个均匀的过程，正常磨损区段在磨耗区的中心区域，但是边缘磨损区段才是最危险的------这意味着滑板和接触线的对中性出了问题。算法里要做边缘磨损和中心磨损的区分报警。
五个真实场景的坑
接下来上点干货，说几个在轨道交通项目里让人掉头发的真实场景：
场景1：电磁干扰让振动信号全乱
动车组的牵引电机是 PWM 变频器驱动的，开关频率 1kHz~5kHz，结果振动传感器把 PWM 的电磁干扰全收进来了。轴箱轴承的特征频率（几十Hz）被淹没在 1kHz 的开关噪声里。
解决方案 ：硬件上用屏蔽双绞线，软件上用自适应陷波器针对 PWM 开关频率做窄带滤波。我们的代码里直接锁频到变频器的开关频率，陷波带宽50Hz。
场景2：温度补偿的伪故障
冬天-20°C时，金属收缩，传感器的偏置电压会漂移；夏天40°C又是另一个值。如果不做温度补偿，算法会把正常的传感器漂移当成设备异常。
解决方案 ：每个传感器出厂前在-40°C~+85°C的温箱里做标定，建立温度补偿表。运行中实时测量环境温度，对信号做补偿。我那段代码里有一个 apply_temp_compensation(voltage, temperature, comp_table) 函数，本质上就是分段线性插值。
场景3：列车过岔的冲击
动车过9号道岔的时候，轮对会有一个横向冲击，这个冲击会被轴箱振动传感器捕捉到，特征上跟轴承外圈剥落的特征非常类似------频率都在BPFO附近。
解决方案 ：加一个位置传感器（比如查询应答器），告诉算法当前列车在哪个区段。过岔区段、前后50米内降低报警灵敏度，或者直接屏蔽。
场景4：弓网接触线的季节形变
夏天接触线热胀冷缩，导线的张力会变化，拉出值的正常范围都变了。冬天设的报警阈值，到了夏天全是误报。
解决方案 ：自适应阈值------用过去30天的数据动态计算正常范围，而不是固定的全局阈值。我们的做法是滚动计算"过去N小时±3σ"作为动态限值。
场景5：车轮多边形的真实案例
去年沈阳局一个项目，动车组在通过某段曲线时，轴箱振动周期性飙升。现场排查了轴承、齿轮箱、电机全没事，最后发现是车轮多边形------车轮在长期制动后踏面产生了周期性的平点，转一圈压一次路面，传到轴箱就成了明显的谐波。
解决方案：通过对比轴箱左右通道的相位差，区分是轴承故障还是车轮问题。车轮多边形的特征是左右通道同步、且谐波次数对应车轮转速。
不是所有车都值得装
最后说点争议性的观点。
行业里有一种"内卷"------不管什么车都要上全监测。我直接反对这个：不是所有列车都适合做预测性维护。
我有一个判断标准，给你参考：
| 列车类型 | 是否值得装PHM系统 | 理由 |
|---|---|---|
| 高速动车组（CR400） | ✅ 必须装 | 价值高、安全责任重 |
| 地铁车辆（8编组批量大） | ✅ 推荐装 | 数据量足够分摊成本 |
| 普速客车（25G/25T） | ⚠️ 选装 | 检修间隔长，投入产出比一般 |
| 货运机车（和谐系列） | ⚠️ 部分子装置 | 走行部可以装，弓网不用 |
| 工程车/调车机 | ❌ 不必装 | 价值低，事后维修更经济 |
为什么？因为预测性维护的核心价值是降低非计划停机和延长设备寿命。如果本身价值密度低、检修周期长、维修成本可控，那装一套几百万元的监测系统，回本周期可能10年以上，这就不是一个好生意了。
青岛那家检修公司的总工跟我说过一句话，我觉得挺到位："不是技术越新越好，是匹配当前业务的最好。我们公司的业务是'做高级修'，所以对'装车前的预测'需求没那么大；但是对'修车后的质量验收'，我们的需求很强烈。"
所以我现在的判断是：先理清楚你修的是哪种车、哪种业务模式，再决定上什么方案。上来就喊"我们要做AI预测"的客户，10个里面有7个其实没想清楚自己要什么。
写在最后
轨道交通的预测性维护，做了三年，我的最大感受是：这个领域最大的护城河不是算法，是数据。
你有10万辆车的轴承数据，你就有10万次的故障经验曲线；你只有1000辆车的数据，你的模型泛化能力就是不行。这事儿跟工业领域不一样，工业里一台产线跑5年能积攒几万小时数据，动车跑5年也就攒几千小时的轴承数据。
所以新入行的同行，先去想办法接入铁路局的数据平台，哪怕只是做一个边缘节点做预处理。有了数据流的入口，模型才有地方跑。
下次有机会我再写一篇轨道交通的"数据链路"------从车地无线传输（4G/5G专网）、到地面数据中心（TDCS/CIR接口）、再到分析平台（这个一般是铁路局自己的系统）。这部分更偏工程实施，但也是这行最值钱的实战经验。
青岛总工说他们最近在搞"修前预测"，也就是车进检修库之前就预测出哪些部件要修。我个人觉得这是个好方向，但也最难------数据不够。我会持续关注，等他们做出成绩了再来拆给你看。