第二章：智能识别系统架构

各位同学，今天我们来聊聊系统架构。说实话，我见过不少做故障诊断的团队，一上来就急着调模型、跑算法，结果做到一半发现数据采不上来，或者采上来的数据根本没法用。嗯，这就是典型的「地基没打好就盖楼」。

我个人习惯，做任何系统之前，先把架构图画清楚。你想想看，一个风机叶片故障识别系统，从传感器采集信号到最后在屏幕上显示结果，中间要经过多少环节？每个环节都可能出问题。今天我就把这四层架构掰开揉碎了讲给你听。

2.1 系统总体架构设计

先看整体。我习惯把系统分成四层：数据采集层、特征提取层、诊断决策层、人机交互层。这四层像流水线一样，数据从底层往上流，决策结果从上往下反馈。

下面这张图是我自己画的架构图，你可以把它当作整个课程的地图。

这张图你最好保存下来。后面每一章的内容，都可以在这张图上找到位置。我记得第一次给客户讲这个架构时，对方技术总监看了五分钟，说：「嗯，这个结构清楚，我们之前就是缺这个。」

2.2 数据采集层

数据采集层是整个系统的「眼睛」和「耳朵」。说白了，你后面算法再牛，数据没采好，一切都是白搭。

我在项目中遇到过最典型的问题：传感器安装位置不对。有一次在风场，工人把振动传感器装在了叶片根部靠近轮毂的位置，结果采到的信号全是轮毂的振动，叶片本身的故障特征完全被淹没了。嗯，这就是典型的「数据污染」。

数据采集层主要包含以下几个部分：

• 传感器选型：振动传感器（加速度计）最常用，频率范围要覆盖叶片故障的典型频段（通常0.5Hz-10kHz）。声发射传感器适合检测早期裂纹，但成本高。
• 采样策略：采样频率至少是最高分析频率的2.56倍。我个人习惯留3-5倍余量，防止混叠。
• 信号调理：放大、滤波、隔离。这一步容易被忽略，但信号质量往往取决于这里。
• 数据存储：原始数据要存，但别全存。我建议存一段时间的原始数据用于离线分析，日常只存特征数据。

2.3 特征提取层

原始信号是「原材料」，特征才是「半成品」。特征提取层的任务，就是把高维的、冗余的原始信号，压缩成低维的、有物理意义的特征向量。

你想想看，一秒采10万个点，直接扔给神经网络？不是不行，但计算量太大，而且容易过拟合。所以我们要做特征提取。

常用的特征有三类：

特征类型	典型特征	适用场景	我的经验
时域特征	均值、方差、峰值、峭度、波形因子	冲击类故障（如叶片裂纹）	峭度对早期故障敏感，但容易受噪声干扰
频域特征	频谱峰值、边频带、谐波能量	周期性故障（如轴承磨损）	边频带分析能定位故障位置，但需要经验
时频域特征	小波包能量、短时傅里叶变换	非平稳信号（如变转速工况）	小波包分解是我最常用的，效果稳定

我曾经在一个项目中，只用峭度这一个特征就检测出了叶片早期裂纹。但后来发现，这个特征在风速变化大的时候会失效。所以后来我改用多特征融合，稳定性好多了。

2.4 诊断决策层

这一层是系统的「大脑」。特征提取完了，接下来就是判断：这个叶片是正常的，还是已经有故障了？如果有故障，是什么类型的故障？严重程度如何？

诊断决策层我一般分三步走：

1. 故障检测：先判断有没有故障。用阈值法或者单分类器，速度快。
2. 故障识别：如果有故障，识别是哪一类。用多分类模型，比如CNN或者随机森林。
3. 故障评估：评估严重程度。这一步最难，需要大量历史数据做回归分析。

这里有个坑，我踩过。一开始我直接用深度学习端到端训练，效果确实好，但模型解释性差。客户问「为什么判断这个叶片有故障？」我答不上来。后来我改成「特征提取+传统分类器」的组合，虽然准确率低了2-3个百分点，但每个判断都能追溯到具体的特征，客户很满意。

2.5 人机交互层

最后一层，也是用户直接接触的一层。说实话，很多技术团队不重视这一层，觉得「功能实现了就行」。但我的经验是，交互设计的好坏，直接决定了系统能不能用起来。

人机交互层要解决三个问题：

• 怎么看：实时监控仪表盘，要一目了然。我习惯用红黄绿三色表示故障等级，绿色正常、黄色预警、红色报警。
• 怎么查：历史数据查询，要支持按时间、按风机编号、按故障类型筛选。最好还能对比不同时间段的特征变化。
• 怎么报：报警推送，要分级。轻微故障发邮件，严重故障发短信+电话。我曾经因为报警太频繁，运维人员直接把系统静音了...后来改成分级报警，问题解决。

还有一个细节：报表生成。运维人员每周要写报告，如果系统能自动生成带图表的PDF报告，他们会非常感激。我在一个项目中加了这个功能，用户满意度直接提升了30%。

好了，系统架构就讲到这里。四层架构，每一层都有它的职责和挑战。后面我们会逐层深入，从传感器选型到模型部署，一步步把这个系统搭建起来。

---

公众号:蓝海资料掘金营，微信deep3321