最开始接手这个任务时我其实有点犹豫。船舶制冷系统故障诊断这个方向算法本身并不算多难真正难的是数据——实船正常运行时故障一年也等不到几次真出了故障维修班组很快就把故障清掉了根本来不及记录完整的温度、压力变化曲线。后来我把思路改成“仿真先造数据SAE 学特征”也就是先用仿真平台把制冷系统的正常和故障工况完整跑一遍再用栈式自编码器Stacked AutoencoderSAE自动提取特征并完成故障分类。整条链路跑通以后验证集上的总体诊断准确率稳定在97%左右几种典型故障的召回率都超过了93%。如果你正打算做制冷系统、旋转机械或者类似的工业设备智能诊断而且手上最缺的就是故障样本那这篇文章应该能给你一条可以照着落地的技术路线。下面我会把系统建模、故障注入、SAE 网络设计和最终验证的完整过程以及那几个最容易翻车的细节一次性写清楚。1. 为什么先做仿真数据集再用 SAE 做诊断1.1 实船故障数据不是没有而是太贵、太少、太不均匀现实里给工业设备做故障诊断最大的阻碍往往不是算法写不出来而是训练样本不够。一条船上的制冷系统可能连续几个月都是健康状态设备一旦出现异常船上电气员、冷藏员会靠经验果断处置留给自动采集系统的时间窗口往往只有十几分钟。等数据分析师拿到数据时通常只看到一条曲线从正常跑到报警后面跟着维修记录中间那段“故障演化过程”是缺失的。就算我们提前布好传感器踏踏实实等故障出现还有一个更现实的问题故障发生概率本身就低而且类型分布极其不均。制冷剂慢性泄漏一年能遇好几次压缩机阀片磨损可能三五年才碰到一次。拿这种天然不平衡的数据去训练一个十几类故障的多分类模型模型一定会变成“分类器里的偏科生”——常见故障分得很准罕见故障基本学不会。仿真在这里的价值就体现出来了。只要系统模型校准得足够准故障类型、故障深度、系统工况都能按需组合以极低的成本批量制造样本。这也是为什么工业智能诊断方向的人做第一版原型系统时基本都会优先选择仿真数据。1.2 SAE 为什么适合这个任务而不是一上来就上大网络有人可能会问既然仿真数据可以批量生成那直接用 CNN、RNN 这类端到端模型不就行了吗这里有一个很容易被忽略的问题。仿真数据的标签虽然源源不断但仿真样本和真实船数据之间始终存在分布偏差。如果从零直接训练一个很大的深度网络它会不自觉地记住仿真环境里那些细微的“数字特征”而不是设备真正的故障规律。模型越深、参数越多在仿真数据上越容易过拟合换到实船数据上表现就越差。SAE 的路线不太一样。它先不看标签用大量数据做“重建输入”的无监督任务在压缩和还原的过程中把最关键的结构性特征提取出来拿到这些特征之后再在最顶层接一个轻量分类器去学故障类别。因为前段特征是在无监督状态下学的它学到的是系统整体状态的结构规律而不是某一类故障的“长相”泛化性会好一些。另一方面制冷系统各测点之间强耦合压缩机排气温度一变蒸发器过热度也跟着跳这种耦合关系恰好适合自编码器的编码-解码结构去刻画。1.3 整条技术路线从建模到评估的五步走这套方法并不是把“仿真系统”和“SAE 模型”两个词拼在一起就算完中间需要一条完整链路。我最终落地的流程如下梳理目标制冷系统的结构和参数确定传感器测点在仿真平台上搭建基准模型用设计工况数据做校准按故障机理设置不同深度、不同工况的故障注入批量生成数据对原始时序做滑窗和统计特征提取划分训练集、验证集和测试集用正常样本预训练 SAE再叠加分类层做有监督微调最后在测试集上评估。有些同行一上来就跳过第2步直接做第3步结果仿真数据和真实设备对不上后面模型再漂亮也只是“仿真内的自嗨”。所以建模校准这一步最不能省。2. 先把对象摸清楚船用制冷系统的故障从哪来、怎么被看到2.1 制冷系统四大件和它们“牵一发动全身”的关系船用制冷系统的核心回路基本就是四大部件压缩机、冷凝器、膨胀阀、蒸发器。制冷剂在压缩机中被压缩成高温高压气体进入冷凝器放热变成液体再经过膨胀阀节流降压降温最后在蒸发器里吸收舱室热量完成一个标准制冷循环。原理听起来不难难就难在这四个部件之间高度耦合。举个例子蒸发器风机转速下降蒸发温度会随之降低蒸发温度降低意味着压缩机吸气压力也降低吸气压力降低又会让压缩比变大排气温度升高。你从传感器上先看到报警的可能是“排气温度偏高”但根因却在蒸发器风机上。这就是典型的耦合干扰。我常用一个生活化类比来解释这件事一套供暖系统里某个房间不热可能是暖气片堵了也可能是分水器阀门坏了还可能只是循环泵扬程不够。三个原因表面都表现为“房间温度低”只盯着温度一个测点根本没法区分。故障诊断的任务就是把“多个原因引起同一表象”这件事拆开。2.2 常见故障模式与它们的参数指纹为了让诊断不变成盲人摸象故障类型尽量要贴近实际。综合某船队近几年的维修记录和同行经验船用制冷系统里最常见的故障大致可以分成下面几类而且每一类都有比较明显的“参数指纹”。我当时做特征和标签设计时就是按这张对照表来的故障位置故障模式典型参数变化建议观测点压缩机排气阀片磨损排气温度上升、吸气压力波动、功率变化不明显排气温度、吸气压力、压缩机电流冷凝器换热管结垢冷凝压力升高、冷凝温度升高、过冷度下降冷凝压力、冷却水进出口温差膨胀阀开度漂移或感温包失效过热度异常升高或降低、蒸发温度变化蒸发压力、过热度蒸发器翅片脏堵或风机故障蒸发温度下降、风侧压差增大、出风温度偏低蒸发温度、风机电流、风压差制冷剂回路泄漏或充注不当高、低压同时偏低排气温度偏高过热度偏高蒸发压力、冷凝压力、排气温度这些参数指纹不是拍脑袋定的它来自制冷系统的热力学关系。比如冷凝器结垢以后换热能力下降冷凝温度必须升高才能把同样多的热量排出去于是冷凝压力上升冷凝器出口的过冷度因为换热不足而下降。这样一串连锁反应在多个测点上都会留下痕迹。2.3 故障程度怎么定义诊断不是“有没有”而是“严重到哪一步”新手容易忽略一件事故障诊断模型的输出不应该只是“有故障/没故障”而应该包含故障类型和严重程度。同样是制冷剂泄漏漏了5%和漏了30%系统表现差异很大决策意义完全不同——前者可能还能坚持到下一港后者必须马上停机检修。所以我在仿真数据生成阶段就把故障分成轻、中、重三档对应参数偏离正常范围的不同幅度。比如制冷剂泄漏以充注量减少5%、15%、30%分别代表轻中重冷凝器结垢以换热系数下降5%、12%、25%来定义。这样做的好处是SAE 学到的不是孤立的“故障类别标签”而是一个连续变化空间里的模式过渡对未来做趋势预测也有帮助。具体百分比需要按实际系统的设计值和容差弹性调整不同厂家的机组差异很大照搬默认值容易失真。3. 仿真模型怎么搭、故障数据怎么造3.1 从设计参数到可校准的基准模型仿真的第一步不是写代码而是拿到和实际系统一致的部件参数。我当时做的一套工程样机是一台中温冷库系统设计蒸发温度在 -18℃ 左右冷凝温度约 38℃。需要先把压缩机排量、换热器面积、风机风量、膨胀阀开度范围这些基础参数填进仿真模型第二步才跑基准工况。模型建完之后最关键的动作是把“正常设计工况”下的仿真输出和厂家样本数据做对比。判断标准不需要苛刻到实验室级别但关键测点偏差要控制在一个合理范围蒸发温度绝对偏差尽量不超过 1.5℃冷凝温度不超过 2℃功率偏差不超过 5%。如果超了优先检查换热系数和压降模型这两个位置——大多数仿真偏差都出在这里。这一步很像做菜之前先试锅热得匀不匀。锅都还没热好就往里下料后面加再多调味也只是掩盖问题。仿真模型没有校准到位就往上堆故障诊断模型一定会在实船数据上被打回原形。3.2 故障注入不是改一个数字那么简单在模型里造故障一定要遵循物理机理不能直接给传感器读数加个偏置就完事。更合理的做法是去修改导致故障发生的底层物理参数。制冷剂泄漏修改系统的制冷剂充注量让系统在低充注量下重新收敛到新的稳态冷凝器结垢降低冷凝器总换热系数或有效换热面积膨胀阀开度异常修改膨胀阀开度范围或过热度设定值蒸发器风机故障降低空气侧风量严重时直接按比例关小。这么做的原因很简单真实故障是系统层面的物理变化传感器上看到的数据异常只是结果不是原因。如果直接给传感器读数加扰动模型学到的是一堆没有物理含义的数值关系到实船数据上根本对不上。故障注入的幅度也要设置成多档而且要交叉覆盖不同工况。我采用的策略是“同故障多深度、同深度多工况”例如制冷剂泄漏的 5%、15%、30% 三档分别在环境温度 25℃、30℃、35℃ 各跑一组这样产生出来的数据同时覆盖故障程度和负荷两个维度模型既学到故障特征又学到工况差异不会偏科。3.3 样本生成与预处理把连续运行曲线切成可用样本仿真跑出来的是一段段连续时间序列而训练 SAE 需要的是固定长度的样本集合。我用的方案是滑窗截取窗长取 120 秒步长取 30 秒每个窗口做一次特征化得到一个训练样本。每个窗口内抽取的统计特征一般包括均值、标准差、最大值、最小值、一阶差分均值、相邻时段的相关系数等。除了原始测点信号还会加入二次计算量比如过热度蒸发器出口温度减蒸发温度、过冷度冷凝温度减冷凝器出口温度等。这类间接特征对诊断极其敏感往往比原始温度压力值更有区分度。样本生成完之后一定要按故障类型检查数据量是否均衡。仿真虽然可以无限造数据但如果你对某类故障只跑了两条曲线模型照样会偏。我当时用了一个很简单的原则先按工况权重生成原始曲线再按故障类别统计样本量哪类不够就在该故障下多跑几轮随机工况直到各类样本数量接近。4. SAE 网络结构设计、训练流程和超参数4.1 自编码器在学什么为什么先预训练再微调自编码器的原理说起来并不复杂输入一个样本经过编码层压缩成低维向量再经过解码层还原成原始输入目标是最小化重构误差。如果网络能用一个很低的维度把输入“重建”出来说明这个低维向量已经抓住了原始数据中最稳定的结构信息这部分结构就是我们要的特征。栈式自编码器就是把多个自编码器一层层堆起来先用第一层把输入压缩成中间表示再把中间表示当作第二层的输入继续压缩逐层提取更抽象的特征。训练时常用的方式是“贪心逐层预训练”——先训第一层固定住再训第二层依次往下。最后把解码部分拿掉接一个分类器用带标签数据对整个网络做微调。为什么不用一步到位的方式训练整个深度网络因为深层网络参数多直接用随机初始化去优化很容易落入局部最优而且仿真样本和真实样本之间的小偏差会被放大。逐层预训练相当于先让每一层都学会一个“合理的特征变换”再让分类器在这个好的特征空间里做判断收敛更稳、对分布偏移的容忍度也更高。4.2 栈式网络结构和分类头的设计我在项目中采用的输入特征维度是 60 维对应各个测点的统计特征和二次计算量。网络主体是四层编码结构维度依次为 60→40→20→10对应的预训练解码结构是 10→20→40→60。完成预训练之后丢掉解码部分在 10 维特征之上拼接一个输出层映射到 8 个类别——1 个正常类加 7 个故障类。中间层激活函数全部用 ReLU避免深层网络出现梯度消失分类输出层用 Softmax。为了防止过拟合编码层之间加了 Dropout比例 0.2同时给权重加上 L2 正则系数设为 0.001。这些参数不算什么惊艳配置但稳定性很好适合作为第一版基线。这个小节想特别提醒的是分类头的类别数量不要一开始就搞太多。8 类是我在仿真数据成熟以后才扩到的前期原型系统只做了 5 类先把主链路跑通再逐步加类别。4.3 训练细节、超参数和代码示意整个训练过程分两阶段。第一阶段预训练只用正常样本因为实际部署时船上的长时间运行状态基本都是正常的先让编码器学会“设备正常时系统状态长什么样”如果预训练阶段混入太多故障样本编码器反而会被故障模式带走。第二阶段微调用全部带标签的仿真样本交叉熵损失学习率调低让分类器在已学到的特征空间上做精细区分。具体超参数如下每层预训练迭代 50 轮批次大小 64学习率 0.001整体微调迭代 50 轮批次大小 64学习率 0.0001优化器使用 Adam随机种子固定方便实验结果复现训练过程监控验证集损失连续 10 轮不下降就提前停止。核心训练流程的伪代码如下示意具体实现可基于开源框架完成# 栈式自编码器训练主流程示例 load normal_samples, fault_samples, all_labels # 第一步标准化 滑窗特征提取 X_normal preprocess(normal_samples, window120s, stride30s) X_all preprocess(all_samples, window120s, stride30s) # 第二步逐层贪婪预训练只使用正常样本 for hidden_dim in [40, 20, 10]: ae build_autoencoder(input_dim当前维度, hidden_dimhidden_dim) for epoch in range(50): loss mse(ae(X_normal), X_normal) 反向传播并更新权重 X_normal ae.encode(X_normal) # 输出作为下一层输入 # 第三步堆叠编码层 分类层全部参数微调 model StackedNet(encoder_hidden[40, 20, 10], num_classes8) model.load_pretrained_weights(预训练权重) for epoch in range(50): loss cross_entropy(model(X_all), all_labels) 反向传播并更新权重(学习率0.0001)伪代码缺了一个环节但很容易忘预训练结束之后的微调阶段不是只训练分类层而是要把整个编码器的参数一起放开微调。我最初试过只训分类层不训编码层效果差了不少因为仿真数据和最终分类目标之间还有一层适配没有完成只有一起微调才能把特征空间调整到最适合故障分类的方向。5. 验证结果与复盘准确率之外还要看什么5.1 评价协议别让总体准确率骗了你仿真数据虽然是可控的但样本分布依然存在不平衡。如果不做干预总体准确率很容易被大类样本顶上去小类故障的识别效果可能很差但你不看分项指标根本发现不了。所以我采用的评价方案是训练集:验证集:测试集 7:1.5:1.5随机切分重复 5 次取均值重点看每个类别的召回率、精确率和 F1同时单独统计“正常类被误报为故障”的比例。正常类的误报率对实际部署是致命的。船上正常运行的设备如果诊断系统三天两头误报值班人员很快就对系统的报警失去信任真故障来了反而没人当回事。这个指标必须单列出来盯。5.2 结果表现与混淆分析我最终拿到的测试集平均结果大致如下数值为多次运行均值故障类别召回率精确率F1正常98.6%98.9%98.7%制冷剂泄漏96.2%96.7%96.4%冷凝器结垢95.1%94.5%94.8%膨胀阀开度异常92.0%93.3%92.6%蒸发器风机故障97.5%96.2%96.8%压缩机阀片磨损93.8%94.0%93.9%制冷剂过充注94.6%95.2%94.9%蒸发器风道堵塞95.3%94.1%94.7%总体准确率约 97.2%但真正值得分析的不是这个 97.2%而是具体类别之间的差距。最容易混淆的组合是“膨胀阀开度异常”和“轻度制冷剂泄漏”。这两类故障在热力学表现上很相似都可能导致过热度偏高、蒸发压力和冷凝压力双双走低仿真曲线上看几乎像同一组模式。SAE 最终把开度异常的召回率压在 92% 左右主要就是被轻度泄漏的样本“抢”了一部分。后来我把训练数据里这两类的轻档样本各增加了一倍同时加重了小类的交叉熵损失权重召回率才提升到 95% 以上。5.3 和传统特征工程方案对比为了说服自己这套方法值得用我把同一份仿真数据同时喂给了三个方案传统阈值规则、手工统计特征加 SVM、SAE。阈值规则最简单只能对单参数突变比较明显的故障有反应综合准确率只有 82% 左右而且跨类别问题基本无解。手工特征加 SVM 是工业界很经典的组合准确率能到 91.5%但特征筛选和调参花了团队差不多一周后续每增加一种故障类型都要重新核一遍特征是否有区分度。SAE 综合准确率 97.2%而加新类型时只需要重新生成对应仿真样本、微调一轮省时省力不少。我并不是劝所有人都无脑抛弃传统方法。如果现场算力有限或者你只关心某一类快速发展、信号特征明显的故障阈值规则和浅层模型反而更可控。但如果目标是多类型诊断、希望模型有一定的自动特征提取能力SAE 这条路线值得投入。6. 这个项目里最容易翻车的四个细节6.1 故障注入幅度不能一味求大很多做仿真诊断的初学者有个通病为了让模型“容易学”把故障幅度设置得特别极端比如让蒸发器风机完全停机、把制冷剂压力压到极低。这种模型训练完之后识别“已经坏到不行”的故障确实很准但实际设备几乎不会给你这么明显的机会——真正的诊断价值在于识别“初期、轻度”的故障预留出处置时间。我后来特意把大部分训练样本集中在轻度到中度故障上早期检出率才真正做起来。6.2 仿真数据和实船数据之间必然存在迁移偏差仿真模型校准得再准在动态响应、传感器噪声、设备老化这些维度上和真实数据也不可能完全一致。SAE 在仿真数据上效果再好直接拿到实船环境也会有性能损失。我的应对办法是部署前收集少量实船正常样本做一次轻量适配把实船正常样本送到网络中观察中间层特征的分布偏移然后用这个偏移对仿真特征做坐标校正。流程不复杂但能明显减少正常样本的误报率。6.3 传感器数量和布置方式往往决定诊断上限SAE 再能提取特征也提取不出传感器没有采集到的信息。有的船上制冷系统只有压缩机排气温度和吸气压力两个测点这种配置下别说深度学习经验再丰富的轮机员也只能判断“系统有问题”判断不了具体故障位置。如果项目条件允许建议至少补齐蒸发器进出口温度、冷凝器进出口温度、冷却水进出口温度、过热度所需温度、压缩机电流和风机电流这几个关键测点。数量不必多但位置一定要覆盖四大部件。6.4 不要一开始就做“全类型大满贯”多分类如果你是这个方向的新手我的建议很直接先做正常/异常二分类把数据流程和网络调通再做故障大类识别比如泄漏、结垢、阀异常、风机异常四类等一切稳定了再去细分故障子类型。一上来就做七八类多分类结果往往是每一类都分得不够好一旦某类样本分布变了整个模型都要重训。我最初就吃过这个亏后来把类别树改成先粗后细的两级结构整个系统才稳定下来。最后再说一个我自己养成的小习惯仿真过程中所有原始曲线我都不会只保留提取好的特征而是把时间序列原样存一份。因为无论是后期调参、查错还是做模型迁移回看原始曲线永远是最快定位问题的路径没有之一。