PLC 数据采集方案横评:Kepware / Node-RED / ThingsBoard 网关 / 自研开源网关

"车间里 30 台 PLC,要把数据送进 MES 和时序库,用什么方案?"

这是工业数字化项目里最高频的问题之一。市面上最常见的四个答案:商业老牌 Kepware、开发者熟悉的 Node-RED、开源平台 ThingsBoard 自带的网关、以及各类开源自研网关。

这篇文章不做"谁最好"的结论------四个方案我都在不同场景里用过或研究过,它们各自出生的语境决定了各自的边界。文章会给出一个五维打分框架,你可以对着自己的项目场景打分选型。最后介绍我因为"现场部署约束"而写的开源网关,供对比参考。

github:https://github.com/Ellisata/iot-gateway · gitee:https://gitee.com/wang4856304/iot-gateway(AGPL-3.0 开源)

一、选型前,先回答三个问题

方案没有绝对优劣,只有场景匹配。动手对比前先回答:

部署环境是什么? 现场工控机能不能装 Docker?有没有公网?操作系统是不是 Win7?
数据去哪? 进自建 MES、进时序库做分析大屏、还是上云平台?
谁维护? 自动化工程师(会 PLC 不一定会编程)、还是你们自己的软件团队?

这三个问题的答案组合,基本就圈定了候选范围。

二、四个方案逐个看

1. Kepware(KepServerEX):行业老牌,商业授权

PTC 旗下的工业连接平台,做了二十多年,协议覆盖(100+ 驱动)和稳定性是行业标杆,大厂 MES 项目里出场率极高。

优点:协议覆盖最广;Client/Server 架构成熟,OPC UA/DA 服务端能力完善;大项目上有商业支持和背书。
痛点 :按驱动/tag 数授权,点位多了授权费不便宜;配置在桌面客户端里点选,批量建点靠 Excel 导入,数千点位维护繁琐;部署要装运行时,交付到无公网的现场要带全套安装包。
适合:预算充足、协议繁杂(尤其有私有协议需求)、需要厂商背书的乙方交付项目。

2. Node-RED:开发者的瑞士军刀

IBM 开源的流式编排工具,Modbus/S7/MQTT 节点拖拽连线就能跑,社区生态庞大。

优点:上手快、灵活度极高;除了采集还能顺手做联动逻辑;免费。
痛点 :它本质是流程编排工具,不是网关------点位管理是"一个节点一个设备"的手工模式,300 台设备就是 300 个节点配置,没有点位表、设备对象的概念;没有断点续传(断网期间数据需要自己接 trigger/catch 节点实现,几乎没人做对);没有管理界面、报警中心、权限体系,这些都要自己搭;流程 JSON 的版本管理对非程序员不友好。
适合:原型验证、小规模(<20 设备)采集、开发者个人项目。

3. ThingsBoard IoT Gateway:开源平台官方网关

ThingsBoard 是最流行的开源 IoT 平台之一,官方 Python 网关负责把 Modbus/OPC UA/BACnet 等设备接入平台。

优点:与 ThingsBoard 平台深度集成,天生上云;配置化程度高;Apache 2.0 许可友好。
痛点 :强绑定 ThingsBoard 生态,数据先进平台再分发,不直连 MES/时序库;Python 运行时 + 平台 + 数据库,一套部署链条不短,与工业现场"无 Docker、无公网"的现实有摩擦;采集吞吐以 IoT 平台场景为准,数千点高频轮询场景要自己评估。
适合:已经在用/计划用 ThingsBoard 平台、设备以 IoT 传感器为主的项目。

4. 开源自研网关(本文以 iot-gateway 为例)

这是我为"单机直连 MES/时序库"场景写的方案:Go 单二进制(约 13MB 发行包),内置 Web 控制台,数据不经过任何平台,采集后直接推送 MQTT / TDengine / InfluxDB。

优点 :部署 = 拷一个文件 (免 CGO 交叉编译,Win/Linux 双平台,install.bat 注册系统服务);管理控制台管设备/点位/通道/报警,数据直推下游不绕平台;断网落盘补发;AGPL-3.0 免费商用(内部部署不触发开源义务)。
痛点:协议覆盖 12 种,远少于 Kepware(私有协议/冷门总线没有);单机架构无集群;项目年轻,社区还在起步,真机兼容性靠用户共建。
适合:现场部署条件受限、数据要直连 MES/时序库、点位规模数千到数十万、预算有限又不想 Node-RED 手搓的项目。

三、五维对比表

维度	Kepware	Node-RED	TB Gateway	iot-gateway
授权成本	商业授权,按驱动/tag	免费 Apache 2.0	免费 Apache 2.0	免费 AGPL-3.0*
部署难度	安装包+运行时	Node.js	Python+平台全家桶	单文件,双击/一条命令
协议覆盖	100+ 最广	常见协议+社区节点	主流工业协议	12 种主流协议
数千点位管理	客户端批量导入	手工节点,吃力	配置文件	控制台在线维护+热加载
断网可靠性	平台级方案	自己实现	依赖平台	内置 outbox 落盘补发
数据去向	OPC/客户端拉取	自由编排	进 ThingsBoard 平台	直推 MQTT/TDengine/InfluxDB
容量参考	未公开	未公开	未公开	压测报告公开:200 万记录/s

* AGPL-3.0:内部部署、经 API/MQTT 对接自有系统不触发开源义务;修改后分发或对外提供服务才需开放对应源码。

诚实声明:容量一行里其他三个方案"未公开"不代表它们弱------是公开资料里找不到可复现的数字。你若有实测数据,欢迎评论区补充,这也是本文的目的之一。

四、一张决策树

复制代码

现场能装运行时/连公网?
├─ 否(无 Docker、Win7 工控机、隔离网段)
│    └─ 单二进制方案优先(Kepware 离线包 或 开源单二进制网关)
└─ 是
     ├─ 已有/计划上 ThingsBoard?
     │    └─ 是 → TB Gateway 顺理成章
     └─ 否
          ├─ 有冷门/私有协议、要厂商背书 → Kepware
          ├─ <20 台设备、开发者自己玩 → Node-RED
          └─ 数千点+、直连 MES/时序库、零授权费 → 开源网关(iot-gateway 类)

五、关于 iot-gateway 的补充信息

既然是对比文,最后把自己的方案说透,方便你验证上面的判断:

协议:Modbus RTU/TCP、西门子 S7、三菱 MC(TCP/串口)、欧姆龙 FINS(UDP/TCP/串口/HostLink)、欧姆龙 CIP、罗克韦尔 CIP、OPC UA;
推送:MQTT(QoS/TLS/遗嘱)、TDengine v3、InfluxDB v3,断网 SQLite outbox 补发;
管理:Web 控制台(中英双语)------设备对象、地址标签、协议动态表单、通道状态、断联报警、Open API(供 MES/ERP 拉数);
容量:假 PLC 服务器压测可复现,Modbus 200 万记录/秒零掉点边界,报告全文开源;
部署:单二进制 / Docker Compose / Windows 服务 / systemd,SQLite 免外部数据库。
gitee:https://gitee.com/wang4856304/iot-gateway
github:https://github.com/Ellisata/iot-gateway

如果你的场景四者都不完全匹配,也欢迎在评论区或 Issue 里描述场景,我可以帮你分析------选型问题本身就有流量,你的问题可能就是下篇文章的素材。

相关阅读:《点位容量不是点数决定的,是帧数 × 往返延迟决定的》《断网不丢数据:工控网关里的 Outbox 模式》。

PLC采集方案横评