一、课程导论与项目全景
大家好，我是老张。在风电圈摸爬滚打了十来年，今天咱们聊聊一个很实际的问题——主轴承温度异常预测。
说实话，我刚入行那会儿，风机坏了全靠人去听、去摸、去看。现在想想，那会儿真是「人肉运维」。后来数据多了，算法强了，我们才开始琢磨：能不能提前知道轴承要出问题？
嗯，这就是这门课要干的事。
1.1 背景与意义：为什么是主轴承？
先问个问题：一台风机最贵的部件是什么？
很多人会说是齿轮箱、发电机。其实主轴承才是那个「默默扛下所有」的角色。它支撑着整个叶轮旋转，一旦坏了，换一次少说几十万，停机损失更是没法算。
我在西北一个风场就遇到过：一台2MW机组，主轴承温度连续三天异常升高，现场兄弟没当回事，结果第四天直接抱死。那叫一个惨——叶片打坏、机舱盖掀飞，维修费够买两台新车了。
所以，主轴承温度异常预测说白了就是：
- 省钱：避免非计划停机，减少大修次数
- 保命：防止轴承失效引发连锁事故
- 提效：从「坏了再修」变成「提前维护」
核心观点：温度是轴承健康状态的「晴雨表」。温度异常往往比振动异常提前数小时甚至数天出现。抓住这个窗口期，就是抓住主动运维的机会。
1.2 项目目标与评估指标
咱们这个项目，目标很明确：构建一个能提前1-6小时预警主轴承温度异常的模型。
但光说「提前预警」太虚了。得用指标说话。我个人习惯用这几个：
| 指标 | 含义 | 我常用的阈值 |
|---|---|---|
| 准确率 | 预测正确的比例 | ≥85% |
| 召回率 | 实际异常中被抓出来的比例 | ≥90% |
| 提前时间 | 预警发出到实际异常的时间差 | ≥2小时 |
| 误报率 | 正常情况被误判为异常的比例 | ≤5% |
一个小经验：召回率比准确率更重要。宁可误报几次，也别漏掉一次真异常。我曾经因为追求准确率把阈值调得太严，结果漏报了一次轴承故障，教训深刻。
1.3 整体技术栈
技术选型这块，我踩过不少坑。现在这套组合是我觉得最顺手的：
- 数据采集：SCADA系统 + 振动传感器（采样率1Hz足够）
- 数据存储：InfluxDB（时序数据库，读写快）
- 数据处理：Python + Pandas + NumPy
- 特征工程：自己写的特征提取库 + tsfresh
- 模型训练：LightGBM（速度快，效果好）
- 模型部署：ONNX + Flask（轻量级API）
你可能会问：为什么不用深度学习？
嗯，我试过LSTM、Transformer。效果确实好一点，但部署成本高、推理慢。在风场那种边缘设备上，LightGBM跑起来更实在。说白了，工业场景讲究的是「够用就好」。
1.4 数据流架构概览
下面这张图是我自己画的，把整个数据流串了一遍。你看完应该能对项目有个整体感觉。
这张图里，我特意加了一条反馈回路。为什么？
因为模型不是一锤子买卖。风场环境在变、机组在老化，模型也得跟着迭代。我见过太多团队，模型上线后就不管了，结果三个月后准确率掉到60%以下。所以，持续监控 + 定期重训才是王道。
1.5 避坑指南
我曾经踩过的三个坑：
- 数据质量：SCADA数据经常有缺失、跳变。别急着建模，先花70%时间做数据清洗。
- 特征选择：别一股脑把所有特征都扔进去。我试过用100多个特征，结果过拟合得一塌糊涂。
- 阈值设定：别用固定阈值。不同季节、不同工况下，温度基线差很多。动态阈值才是正解。
好了，第一章就聊到这儿。后面的章节，咱们会一步步把这张图里的每个环节都拆开揉碎，手把手带你走一遍。
记住：做工业算法，慢就是快。数据搞扎实了，模型自然就稳了。