开源预测性维护工具链从采集到可视化的全流程方案说真话2024年那会儿我在江苏一家做纺织机械的厂做预测性维护的时候预算卡得死死的整个项目砍到 80 万。甲方一开始非要上 IBM Maximo被我直接否了——不是说它不好是这个预算根本撑不起商业版 license。最后我们花了大概 60 万把整套系统从传感器一路干到可视化全用开源工具效果还出奇地好。后来我把这套方案复制到了另外两个项目一个食品厂、一个水处理厂基本都跑通了。今天就把这套工具链摊开讲。一、数据采集层用什么把传感器数据搞出来工厂里的传感器五花八门但绝大多数都是这两种协议Modbus TCP/RTU老一辈 PLC 和工业仪表标配OPC UA稍微新一点的设备都支持但问题是传感器数据出来之后怎么扔到数据库这就得用一个中间人了。我现在的首选是TelegrafInfluxData 出品理由很简单插件多、轻量、配置简单。一个 4 核 8G 的工控机上跑 Telegraf同时接 200 个测点完全没问题。这是我们项目里常见的配置长这样# telegraf.conf 关键片段 [[outputs.influxdb_v2]] urls [http://influxdb:8086] token ${INFLUX_TOKEN} organization phm-org bucket vibration [[inputs.modbus]] name spindle_vibration slave_id 1 timeout 3s # 踩坑提醒timeout 别设太小网络抖动一下就丢点。我们之前用 1s 丢了 15% 的数据惨不忍睹。注意这里有个细节timeout 我给到 3 秒。之前用 1 秒的时候某天交换机有个端口闪断了一下结果那 4 个小时的数据全丢了事后根本补不回来——这种沉默型丢数据是最致命的。如果你车间里有那种很老、只支持串口的传感器比如某些称重仪表那 Telegraf 也支持加个 RS485 转以太网模块就行。反对意见有人觉得 Telegraf 太轻量不如商业软件稳定。我的看法是Telegraf 出问题多半是配置错误商业软件出问题你都不知道该找谁。至少前者我能 debug。二、消息队列要不要加一层 MQTT我们被问过最多的问题是要不要加一个消息队列比如MQTT 5.0配 EMQX 或 Mosquitto。我的观点是如果你的设备数 ≤ 50 台没必要50-200 台建议加200 台以上必须加。50 台以下Telegraf 直接写 InfluxDB 完全够用没什么瓶颈。50-200 台加一层 MQTT 解耦一下Telegraf 挂了不影响数据缓冲。EMQX 的企业版收费但开源版够用。我们某项目里跑了 180 台设备EMQX 5.x 单节点峰值处理 8000 msg/sCPU 占用没超过 40%。不过踩过两个坑Topic 设计要扁别用/factory/area1/line3/spindle/temperature这种嵌套几十万 Topic 会让 EMQX 内存爆掉。我们直接/vib/spindle/{device_id}就完事。EMQX 的 mnesia 数据库要定期清理不然重启一次要等 5 分钟才接得上。三、存储层InfluxDB 还是 TDengine时序数据库这块儿我和同行吵过很多次。我用过的有三款InfluxDB 2.7、TDengine 3.0、TimescaleDB 2.x。简单粗暴地说结论吧场景推荐单工厂、数据量 ≤ 5 亿点InfluxDB 2.x多工厂汇聚、数据量大TDengine 3.x已经用 PostgreSQL 生态TimescaleDBTDengine 的压缩比确实猛我们某客户压缩比是 18:1比 InfluxDB 强不少。但它的 SQL 方言比较特殊团队学习成本在那摆着。我们某项目里跑的是InfluxDB 2.7 Grafana 10.x典型的够用就好组合。InfluxDB 单机能撑到 5 亿点要看 retention policy 和 cardinality。再多就要上集群了——集群版也是开源免费的但运维复杂度上去一档。代码层面这是我每天早上都会跑的一段查询告诉你昨天系统有没有异常// InfluxDB Flux 查询昨天报警次数 from(bucket: vibration) | range(start: -1d) | filter(fn: (r) r._measurement alarm) | filter(fn: (r) r.severity critical) | count() // 踩坑提醒filter 别写在 range 之前老版本性能差到你想哭。注意这里filter 一定写在 range 之后。这个顺序反过来的话查询性能会差好几倍。InfluxDB 的 query planner 这些年改进了不少但这种基础规范还是要遵守。四、可视化Grafana但别只会用面板可视化层几乎没有悬念就是Grafana 10.x。但我想说一个不那么主流的观点Grafana 不只是画图工具它真正的价值是报警分级 多端推送。我们项目里把 Grafana 报警分成了三级级别触发条件通知渠道Critical设备故障概率 0.8短信 电话 钉钉群Warning设备故障概率 0.5-0.8钉钉群 邮件Info设备异常征兆仅看板这套分级不是拍脑袋的是和老师傅磨了3轮才定的。比如 Critical 必须电话老师傅们都有不看钉钉的习惯——这个反直觉但很真实。Grafana 还有个超能力变量 Dashboard 模板化。我们一个工厂 30 台设备每台都得有一个健康度面板。用变量${device_id}做模板之后1 个 Dashboard 复用 30 次。一个月改一次展示逻辑做个用户故事甲方能不能把温度也显示出来 我们沉默1分钟改个 panel重新发布 甲方好感度 10五、流程编排Node-RED 是个被低估的瑞士军刀很多人不知道Node-RED能干嘛但我可以告诉你——它是我们项目里仅次于 Telegraf 的工具人。它的典型用途有三个数据清洗比如把温度值从 modbus 原始 uint16 转成工程值业务逻辑比如同一台设备连续三次报警才升级为 Critical第三方对接比如把报警推送到企业微信或者钉钉我经常看到有人把它当 toy但说句实话在中小工厂里Node-RED 比 Apache NiFi 实用 10 倍。NiFi 太重还需要 Java 环境工控机上跑起来有点杀鸡用牛刀。反对意见有人说 Node-RED 不适合生产环境。我感觉这个观点有点保守了。我们跑过最长的一版 Node-RED 流程连续稳定运行了 14 个月中间没重启过处理的报警超过 1.2 万次。六、机器学习层把模型塞进去哪里这块有同学会问模型部署咋搞如果是简单的统计阈值3σ、移动平均其实 Grafana 都能做。如果是稍微复杂一点的孤立森林、XGBoost 1.7 这种建议用Python FastAPI单独起一个推理服务。去年我们搞了一个油液光谱分析的 XGBoost 模型包装成 FastAPI 服务塞在工控机上。每 5 分钟被 Node-RED 调一次返回预测结果写回 InfluxDB。这个套路简单粗暴但管用。# FastAPI 推理服务 from fastapi import FastAPI import joblib app FastAPI() model joblib.load(rul_model.pkl) app.post(/predict) def predict(features: dict): X [[features[mean_temp], features[vib_rms], features[viscosity]]] rul_hours model.predict(X)[0] return {rul_hours: round(rul_hours, 1)} # 踩坑提醒模型文件要和推理版本严格对齐不然加载报 type error。注意这里有个细节模型文件的 sklearn 版本要和训练环境一致。我们之前踩过坑——本地用 1.3.2 训练工控机部署的镜像里是 1.2.0一加加载就报错。后来学乖了Docker 镜像里固定版本RUN pip install scikit-learn1.3.2写在最后开源不代表免费。我给你算算账——上面这套工具链省下来的 license 费用是 60-100 万但投入 5 个工程师 × 2 个月 ≈ 80 万的工时。两边基本打平。但是反过来想你换来的是什么呢是数据主权 长期可维护性。商业软件每涨一次价、每改一次 API你就得跟着重做一遍。开源工具虽然糙一点但你可以 fork 它可以改它可以一直用下去。我现在的选型原则就一条关键路径用开源依赖专业支持的部分用商业。比如我们 MQTT Broker 一直用 EMQX 开源版但有个别客户对稳定性有极致要求就让他们花钱买企业版——这种钱花得值。一点碎碎念吧工具选型不用太纠结Grafana InfluxDB Telegraf Node-RED 这个组合能解决 80% 的预测性维护场景。先跑起来再优化比一开始就追求完美架构重要得多。