第2章系统总体架构设计

2、系统总体架构设计：数据采集层、数据传输层、数据存储层、智能分析层、预警展示层的分层架构

做风电故障预测系统，说白了就是跟数据打交道。我见过不少团队一上来就急着写算法，结果数据采不上来、传不过去，最后全白搭。所以咱们得先把架构搭稳了。

我个人习惯把整个系统分成五层：数据采集层、数据传输层、数据存储层、智能分析层、预警展示层。每一层各管一摊事，层与层之间通过标准接口对接。这样设计的好处是——哪一层出了问题，单独修就行，不用动整个系统。

  核心原则： 分层解耦，各司其职。每一层只关心自己的输入和输出，不越界。

2.1 数据采集层 — 地基要打牢

这一层负责从风机上把原始信号拿下来。说白了就是传感器和PLC的活。

我参与过的项目里，一台2MW风机大概有80~120个测点。包括：

振动信号：齿轮箱、发电机、主轴轴承，采样率通常2kHz~10kHz
温度信号：齿轮箱油温、绕组温度、轴承温度，每秒1个点
电气参数：电压、电流、功率、频率，每秒10个点
环境参数：风速、风向、环境温度、气压，每秒1个点
状态信号：桨距角、偏航角度、刹车状态、并网状态

我的经验： 振动传感器安装位置特别关键。我曾经遇到一个项目，传感器装在了齿轮箱的薄弱位置，结果数据全是结构共振，根本没法用。后来重新打了安装座才解决。

采集频率怎么定？我一般遵循这个原则：

信号类型	推荐采样频率	说明
振动（齿轮箱）	5~10 kHz	能捕捉到齿轮啮合频率
振动（轴承）	2~5 kHz	滚动体故障特征频率
温度	0.1~1 Hz	温度变化慢，没必要高频
电气量	10~50 Hz	捕捉谐波和暂态
风速/转速	1 Hz	够用，再高就是浪费存储

2.2 数据传输层 — 别让数据卡在路上

数据采上来了，怎么传到服务器？这层我踩过不少坑。

目前主流方案有几种：

MQTT：轻量级，适合窄带宽场景。我习惯用QoS=1，保证至少一次送达
OPC UA：工业标准，安全性好，适合场站内局域网
4G/5G：偏远风场首选，但要注意流量费用
光纤环网：大型风场内部骨干网，稳定可靠

注意： 我曾经遇到一个项目，用4G传振动数据，一天下来流量跑了2个G，运营商直接限速了。后来改成边缘端先做特征提取，只传特征值，流量降到原来的1/10。

数据传输协议我推荐这样设计：

// 数据包格式示例（JSON）
{
  "turbine_id": "WF-001",
  "timestamp": "2025-03-15T14:30:00.000Z",
  "signals": {
    "vibration_gearbox": [0.12, 0.15, 0.11, ...],  // 1024点
    "temp_oil": 65.3,
    "wind_speed": 8.2,
    "power": 1850.5
  },
  "status": "running"
}

2.3 数据存储层 — 存得下，查得快

数据到了服务器，得找个地方存起来。这里有个矛盾：振动数据量大，但查询频率低；状态数据量小，但查询频率高。

我的做法是混合存储：

时序数据库（InfluxDB / TimescaleDB）：存振动波形、温度趋势、风速序列。按时间分区，自动过期清理
关系数据库（PostgreSQL）：存风机台账、报警记录、维修工单。结构化数据，方便关联查询
分布式文件系统（MinIO / HDFS）：存原始振动文件、日志文件。冷数据，按需归档

  存储策略建议：

  - 振动原始数据：保留30天，之后压缩为特征值

  - 温度/风速等慢变信号：保留1年

  - 报警记录：永久保存

  - 模型训练数据：按项目周期保存

2.4 智能分析层 — 这才是核心

数据存好了，轮到算法上场了。这一层我把它分成三个模块：

数据预处理：去噪、插值、归一化。嗯，这一步千万别省，我见过有人直接把原始数据扔进模型，结果准确率不到50%
特征提取：时域特征（均值、方差、峰值）、频域特征（FFT频谱、包络谱）、时频特征（小波变换）
模型推理：故障分类、剩余寿命预测、异常检测

举个例子，齿轮箱故障预测的流程：

# 伪代码示意
def predict_gearbox_fault(vibration_data):
    # 1. 去直流分量
    data = vibration_data - np.mean(vibration_data)
    # 2. 计算包络谱
    envelope = hilbert_transform(data)
    spectrum = fft(envelope)
    # 3. 提取边频带能量
    sideband_energy = extract_sideband(spectrum, gear_mesh_freq)
    # 4. 阈值判断
    if sideband_energy > threshold:
        return "齿轮磨损预警"
    else:
        return "正常"

避坑指南： 我曾经在模型训练时用了全部历史数据，结果模型在换季时频频误报。后来发现是温度变化导致特征偏移。解决办法是加入环境温度作为协变量，或者按季节分别训练模型。

2.5 预警展示层 — 让数据说话

分析结果出来了，得让人看得懂。这一层我强调三个字：快、准、清。

快：预警延迟不超过30秒。从传感器采集到屏幕显示，端到端延迟要可控
准：误报率要低。我见过一个场站一天报警200多次，运维人员直接关掉了报警功能
清：一看就明白。不要给运维人员看一堆数字，用颜色、图表、趋势线说话

展示方式我一般分三级：

级别	颜色	响应方式	示例
提示	蓝色	系统记录，无需立即处理	轴承温度缓慢上升
预警	黄色	推送APP，建议24小时内检查	齿轮箱振动超标
报警	红色	声光报警，立即停机检查	发电机超温+振动突变

重要提醒： 预警阈值不能拍脑袋定。我习惯用统计方法——先收集3个月正常运行数据，取99.7%分位数作为初始阈值，再根据实际误报情况微调。这样比凭经验设阈值靠谱得多。

好了，五层架构就聊到这儿。每一层都有它的门道，但核心思路就一个——让数据从风机到屏幕，流得通、存得住、算得准、看得懂。后面几章咱们会一层一层深入进去，把每个环节的坑都填平。

📚 课程目录

2、系统总体架构设计：数据采集层、数据传输层、数据存储层、智能分析层、预警展示层的分层架构

2.1 数据采集层 — 地基要打牢

2.2 数据传输层 — 别让数据卡在路上

2.3 数据存储层 — 存得下，查得快

2.4 智能分析层 — 这才是核心

2.5 预警展示层 — 让数据说话