拓冰网站定制 
工业现场的数据上云很多人卡在第一步PLC 里的数据怎么稳定、低成本地送到 Web 端。传统做法是买一套组态软件加授权成本高、扩展性差想接个自定义看板或者推给第三方系统处处受限。这两年我陆续做了几个从 PLC 采集到 Web SCADA 展示的完整项目从台达、汇川、西门子 S7-200 SMART 到三菱 FX 系列都碰过最终沉淀出一套相对通用的方案工业智能网关负责现场协议采集MQTT 做消息总线Node.js 做数据接入与 Web 服务。整套链路跑通之后加一个采集点、换一个展示页面成本几乎可以忽略。这篇就把这套方案从选型、搭建到落地的完整过程拆开讲适合有 PLC 基础但没接触过物联网链路的朋友也适合想从传统组态转向 Web SCADA 的工程师参考。1. 为什么放弃传统组态转向网关加 MQTT 加 Node.js1.1 传统上位机方案的三个硬伤先说清楚为什么要换方案不然很容易陷入能用就行的惯性。传统上位机方案通常是 PLC 通过串口或以太网连到一台工控机工控机上跑组态软件组态软件再通过 OPC 或者自有协议把数据给到其他系统。这套东西在单机、单车间场景下没问题但一旦要联网、要多端展示、要对接 MES 或者云平台问题就集中爆发了。第一个硬伤是授权成本与点数绑定。组态软件的点数授权是线性涨价的一个项目几百个点授权费用可能比硬件还贵。而且很多组态软件的外部接口是单独收费的想通过 API 把数据推出去又是一笔钱。第二个硬伤是协议封闭。组态软件采集上来的数据往往只能在自己的生态里流转。想接一个自定义的 Web 看板或者把数据推给第三方的数据分析平台要么买它的接口模块要么做二次开发周期长、依赖厂商。第三个硬伤是部署与运维重。一台工控机放在现场Windows 系统要打补丁、要防病毒、要防断电组态软件升级还可能影响正在跑的项目。现场环境粉尘大、温度高工控机硬盘故障是家常便饭。1.2 网关加 MQTT 加 Node.js 的分工逻辑换成网关加 MQTT 加 Node.js 之后这三者的分工非常清晰各干各擅长的事。工业智能网关负责最底层的协议适配。它向下通过 RS485、RS232、以太网等物理接口连接 PLC、变频器、仪表向上把采集到的数据统一成一种轻量的消息格式。网关的核心价值在于它内置了大量工业协议驱动比如 Modbus RTU、Modbus TCP、西门子 S7 协议、三菱 MC 协议、欧姆龙 FINS 等你不需要自己写协议解析代码配置一下寄存器地址就能读到数据。MQTT负责消息的传输与分发。它是一种发布订阅模式的消息协议特别适合工业场景带宽占用小、支持断线重连、支持 QoS 等级、天然支持一对多分发。网关把数据发布到某个主题任何订阅了这个主题的客户端都能收到Web 服务、手机 App、数据分析程序可以同时订阅互不干扰。Node.js负责数据接入与 Web 服务。它订阅 MQTT 主题把数据存下来内存、时序数据库或者关系库同时对外提供 HTTP 接口和 WebSocket 推送前端页面就能实时刷新。Node.js 的事件驱动模型特别适合这种大量并发连接、低计算量的场景一台普通服务器扛几千个 MQTT 连接和 WebSocket 连接毫无压力。1.3 这套方案适合什么样的项目不是所有项目都适合这套方案我把它适用的边界说清楚避免生搬硬套。适合的场景需要多端展示PC、手机、大屏、需要对接第三方系统、采集点分散在多个车间或厂区、预算有限但要求可扩展、需要做数据留存和分析。不太适合的场景对实时性要求极高毫秒级闭环控制、现场完全没有网络基础设施且不允许布线、项目规模极小就十几个点且永远不扩展。这些场景用传统组态或者本地 HMI 反而更省事。提示网关加 MQTT 加 Node.js 这套链路本质上是把采集和展示解耦。采集端只管把数据发出来展示端只管订阅。这个解耦是整套方案灵活性的来源也是后面所有设计决策的出发点。2. 工业智能网关的选型与现场接线要点2.1 网关选型要看哪几个参数市面上的工业智能网关品牌很多价格从几百到几千不等。选型的时候不要只看价格下面这几个参数直接决定项目能不能顺利落地。参数项说明建议下行协议支持网关能对接的 PLC 和仪表协议至少覆盖 Modbus RTU/TCP西门子、三菱、台达、汇川等主流品牌驱动要齐全上行协议支持网关对外发送数据的协议必须支持 MQTT最好同时支持 HTTP、Modbus TCP 转发的串口数量RS485/RS232 接口数量现场仪表多的话至少 2 路 RS485网口数量以太网接口数量至少 1 路用于连接 PLC 和上行网络采集点数支持的最大采集变量数按实际点数的 1.5 倍预留边缘计算能力是否支持脚本、公式、报警有的话可以做数据预处理减轻服务端压力断网缓存断网时是否缓存数据工业现场网络不稳定这个功能很关键我个人的经验是下行协议驱动的齐全程度比硬件参数更重要。有些网关硬件配置很漂亮但某个品牌的 PLC 驱动写得不好读数据经常超时或者读错地址这种坑非常难排查。选型前最好拿现场实际的 PLC 型号问厂商要一份驱动支持列表确认能读能写。2.2 现场接线与网络规划接线这块看似简单但现场出问题十有八九是接线和网络规划没做好。串口接线要注意 RS485 的 A、B 线不要接反接反了通信不上但不会烧设备排查起来很费时间。多个从站挂在同一条 RS485 总线上时要采用手拉手的方式不要星型分支分支会导致信号反射。总线两端要接终端电阻一般 120 欧姆。波特率、数据位、停止位、校验位这几个参数网关和 PLC 必须完全一致差一个都通不了。网络规划方面如果 PLC 是网口通信网关和 PLC 要在同一个网段。我习惯给网关单独规划一个管理网段和办公网隔离避免办公网的广播风暴影响采集。如果现场有多台网关每台的 IP 要提前规划好做好台账不然后期维护找不到设备。供电方面网关一般用 24V 直流供电要和 PLC 的供电分开走线避免 PLC 启停时的电压波动影响网关。有条件的话给网关配一个小型 UPS断电时能撑几分钟让网关把缓存数据发出去。2.3 网关侧的数据点配置网关配置的核心工作是建立数据点表。所谓数据点表就是把 PLC 里的寄存器地址、数据类型、缩放系数、单位等信息整理成一张表然后在网关的配置界面里逐个录入。以读取西门子 S7-200 SMART 的一个温度值为例假设温度存在 VW100 寄存器里实际值是放大 10 倍的整数比如 256 表示 25.6 摄氏度那么配置大概是这样的变量名temp_01寄存器地址VW100数据类型int16缩放系数0.1单位摄氏度采集周期1000ms这里有个容易忽略的点采集周期不是越短越好。Modbus RTU 是轮询机制如果一条总线上挂了 10 个从站每个从站采集周期都设 100ms那总线根本忙不过来会出现大量超时。合理的做法是按数据变化频率分组变化快的比如电机电流设 500ms 到 1s变化慢的比如温度、液位设 5s 到 10s。注意网关配置完成后一定要用网关自带的调试工具或者 MQTT 客户端先确认数据能正常发出来再去搭后面的服务端。现场排查问题的成本远高于在办公室排查。3. MQTT 服务端的搭建与主题设计3.1 MQTT 服务端选型与安装MQTT 服务端Broker是整个链路的中枢所有数据都经过它转发。选型上开源方案里 Mosquitto 轻量、稳定、资源占用低适合中小规模项目EMQX 功能更全支持集群、规则引擎、Dashboard适合规模较大或者需要做数据桥接的场景。以 Mosquitto 为例在 Linux 服务器上安装非常直接。CentOS 7.9 环境下# 安装 mosquitto yum install -y epel-release yum install -y mosquitto mosquitto-clients # 启动并设置开机自启 systemctl start mosquitto systemctl enable mosquitto # 查看状态 systemctl status mosquitto默认配置下 Mosquitto 只监听本地 1883 端口如果要让网关从外部连进来需要修改配置文件/etc/mosquitto/mosquitto.conf# 监听所有网卡的 1883 端口 listener 1883 0.0.0.0 # 允许匿名连接内网测试用生产环境务必关闭 allow_anonymous true生产环境一定要关闭匿名连接配置用户名密码认证。Mosquitto 的用户管理用mosquitto_passwd命令# 创建密码文件并添加用户 mosquitto_passwd -c /etc/mosquitto/passwd gateway_user # 按提示输入密码 # 再添加一个 Web 服务用的用户 mosquitto_passwd /etc/mosquitto/passwd web_user然后在配置文件里指定密码文件并关闭匿名allow_anonymous false password_file /etc/mosquitto/passwd改完配置记得重启服务并且检查防火墙有没有放行 1883 端口。3.2 主题层级的设计原则MQTT 的主题设计是很多人忽略但影响深远的一件事。主题设计得好后期扩展、权限控制、数据分流都很轻松设计得乱后面想加个功能就得改所有客户端。主题用斜杠分层我一般按项目/厂区/设备类型/设备编号/数据类型这样的层级来设计。举个例子factory_a/workshop_1/plc/plc_001/realtime factory_a/workshop_1/plc/plc_001/alarm factory_a/workshop_1/meter/meter_005/realtime这样设计的好处是订阅的时候可以用通配符灵活匹配。匹配单层#匹配多层。比如factory_a/workshop_1/plc//realtime订阅一号车间所有 PLC 的实时数据factory_a/#订阅 A 厂区所有数据factory_a/workshop_1/plc/plc_001/#订阅某台 PLC 的所有类型数据主题里不要放具体数值数值放在消息体里。主题只用来标识这是什么数据消息体里放数据是多少、什么时间采集的。消息体用 JSON 格式可读性和扩展性都好{ deviceId: plc_001, timestamp: 1735689600000, values: { temp_01: 25.6, pressure_01: 0.85, motor_speed: 1450 } }3.3 QoS 等级与保留消息的取舍MQTT 有三个 QoS 等级很多人不知道该选哪个。简单说QoS 0最多发一次不保证到达。适合高频、可丢失的数据比如实时曲线刷新。QoS 1至少发一次可能重复。适合大多数工业数据采集场景。QoS 2恰好发一次开销最大。适合计费、报警确认这类不能重复不能丢失的场景。工业采集我一般用 QoS 1。因为网关和 Broker 之间的网络相对稳定QoS 1 的开销可以接受而且能保证数据不丢。QoS 2 的四次握手在高频采集下开销太大不划算。保留消息Retained Message是个很实用的特性。当网关把一条消息设为保留消息发布后Broker 会保存这条消息的最后一条任何新订阅该主题的客户端会立刻收到这条消息。这个特性特别适合 Web 页面首次加载时快速拿到当前值不用等下一次采集周期。但保留消息也有坑如果主题设计得太多太细每条都设保留消息Broker 的内存会被大量占用。我的做法是只对当前值这类主题设保留消息历史数据主题不设。3.4 用 MQTT Explorer 做链路验证在正式写 Node.js 代码之前强烈建议先用 MQTT Explorer 这个图形化客户端验证链路。它能连上 Broker订阅主题实时看到消息内容还能看到保留消息和主题树结构。验证步骤很简单打开 MQTT Explorer填入 Broker 地址、端口、用户名密码连接成功后订阅factory_a/#然后看网关有没有数据发过来。如果能看到数据说明网关到 Broker 这一段通了接下来写 Node.js 就只是订阅和存储的事。如果看不到问题就在网关侧或者网络侧先解决这一段。这个分段验证的思路非常重要。整条链路涉及网关、网络、Broker、Node.js、前端多个环节一次性全搭好再调试出了问题根本不知道是哪一段。分段验证每段确认通了再往下走效率高得多。4. Node.js 数据接入服务的实现4.1 Node.js 环境准备与版本选择Node.js 的安装本身不复杂但版本选择有讲究。工业项目我建议用 LTS长期支持版本比如 20.x 或者 22.x 的 LTS。不要用最新的实验版本也不要用太老的版本老版本可能不支持某些新语法和库。Windows 上直接去官网下载安装包一路下一步就行。Linux 上推荐用 NodeSource 的源安装比系统自带的版本新# CentOS 7.9 安装 Node.js 20.x curl -fsSL https://rpm.nodesource.com/setup_20.x | bash - yum install -y nodejs # 验证安装 node -v npm -v如果服务器不能联网需要离线安装那就下载对应的二进制包解压配置环境变量。麒麟 V10 ARM 架构的服务器也是类似思路下载 ARM64 的包。验证是否安装成功除了node -v还可以跑一句node -e console.log(ok)能输出 ok 就说明环境没问题。4.2 用 mqtt.js 订阅网关数据Node.js 里操作 MQTT 最常用的库是mqtt也就是 mqtt.js。先初始化项目并安装依赖mkdir scada-server cd scada-server npm init -y npm install mqtt然后写一个最简的订阅脚本const mqtt require(mqtt); const client mqtt.connect(mqtt://127.0.0.1:1883, { username: web_user, password: your_password, clientId: scada_server_ Math.random().toString(16).slice(2, 8), clean: true, reconnectPeriod: 5000 }); client.on(connect, () { console.log(MQTT connected); client.subscribe(factory_a/#, { qos: 1 }, (err) { if (err) console.error(subscribe failed, err); else console.log(subscribed); }); }); client.on(message, (topic, payload) { try { const data JSON.parse(payload.toString()); console.log(topic, data); // 这里做数据存储和转发 } catch (e) { console.error(parse error, e.message); } }); client.on(error, (err) { console.error(MQTT error, err); });几个关键点说明一下。clientId要保证唯一否则两个客户端用同一个 clientId 会互相踢下线。reconnectPeriod设置自动重连间隔网络抖动时能自动恢复。clean: true表示不保留会话状态如果希望断线重连后还能收到离线期间的消息要设成false并配合固定的 clientId。4.3 数据落库内存、时序库还是关系库数据订阅到之后存哪里是个关键决策。三种选择各有适用场景。内存存储最简单用一个 Map 存每个设备的最新值Web 页面通过 WebSocket 拿实时数据。优点是快缺点是重启就丢且不能查历史。适合只做实时监控、不需要历史的场景。时序数据库比如 InfluxDB、TDengine专门为时间序列数据设计写入快、压缩率高、按时间范围查询效率高。适合需要存历史曲线、做趋势分析的场景。TDengine 对工业场景支持很好还有免费的社区版。关系数据库比如 MySQL、PostgreSQL适合需要和业务数据关联的场景比如把采集数据和工单、设备台账关联起来。但高频写入对关系库压力较大一般会做降采样比如原始数据存时序库分钟级聚合数据存关系库。我实际项目里最常见的组合是内存存最新值 时序库存原始数据 关系库存聚合和业务数据。三者各司其职查询的时候按需取。4.4 对外提供 HTTP 接口与 WebSocket 推送Node.js 服务订阅到数据后要对外提供两种接口一种是 HTTP 接口用于查询历史数据、设备列表、配置信息另一种是 WebSocket用于实时推送。HTTP 接口用 Express 或者 Fastify 都很方便。WebSocket 用ws库。下面是一个把 MQTT 数据和 WebSocket 打通的最小示例const express require(express); const http require(http); const WebSocket require(ws); const mqtt require(mqtt); const app express(); const server http.createServer(app); const wss new WebSocket.Server({ server }); // 存最新值 const latestValues new Map(); // WebSocket 连接管理 wss.on(connection, (ws) { console.log(ws client connected); // 连接建立时先把当前所有最新值推一遍 ws.send(JSON.stringify({ type: snapshot, data: Object.fromEntries(latestValues) })); }); // MQTT 订阅 const client mqtt.connect(mqtt://127.0.0.1:1883, { username: web_user, password: your_password }); client.on(connect, () { client.subscribe(factory_a/#, { qos: 1 }); }); client.on(message, (topic, payload) { const data JSON.parse(payload.toString()); latestValues.set(topic, data); // 广播给所有 WebSocket 客户端 const msg JSON.stringify({ type: update, topic, data }); wss.clients.forEach((ws) { if (ws.readyState WebSocket.OPEN) ws.send(msg); }); }); // HTTP 接口 app.get(/api/latest, (req, res) { res.json(Object.fromEntries(latestValues)); }); server.listen(3000, () console.log(server on 3000));这段代码虽然简单但已经包含了完整的核心逻辑订阅、缓存、广播、查询。实际项目里再往上加认证、日志、错误处理、数据落库即可。提示WebSocket 广播的时候要注意如果客户端很多逐个 send 会有性能问题。生产环境可以用发布订阅模式在服务内部再做一层分发或者用 Socket.IO 这类封装好的库。5. 从数据到画面Web SCADA 前端的实现思路5.1 实时数据绑定的基本模式前端拿到 WebSocket 推来的数据后要把它绑定到画面上。最朴素的做法是每个数据点对应一个 DOM 元素收到更新就改这个元素的文本或者样式。但工业画面往往有几百个点逐个操作 DOM 性能很差。更好的做法是数据驱动视图。用 Vue 或者 React 这类框架把数据放在响应式对象里视图自动更新。比如用 Vue// 数据存储 const state reactive({ devices: {} }); // WebSocket 收到消息后更新 ws.onmessage (e) { const msg JSON.parse(e.data); if (msg.type update) { state.devices[msg.topic] msg.data; } };模板里直接绑定state.devices[factory_a/workshop_1/plc/plc_001/realtime].values.temp_01数据一变视图就变不用手动操作 DOM。5.2 用 SVG 或 Canvas 绘制工艺画面Web SCADA 的画面通常包括设备图形、管道、仪表盘、趋势曲线。绘制方式有两种主流选择SVG 和 Canvas。SVG是矢量图形每个图形元素都是 DOM 节点可以用 CSS 和 JavaScript 直接操作适合画面元素不多、需要交互点击、悬停的场景。工艺流程图、设备状态图用 SVG 很合适。Canvas是位图绘制性能好适合元素非常多或者需要高频重绘的场景比如实时趋势曲线、大量数据点的散点图。但 Canvas 里的元素不是 DOM交互要自己算坐标。实际项目里经常混用工艺画面用 SVG趋势曲线用 Canvas或者用 ECharts 这类图表库它底层用 Canvas。5.3 趋势曲线与报警展示趋势曲线是 Web SCADA 的刚需。实现方式有两种一种是前端定时从 HTTP 接口拉历史数据用 ECharts 画出来另一种是 WebSocket 推实时数据前端维护一个滑动窗口不断往曲线里追加点。实时曲线要注意数据降采样。如果采集周期是 1 秒一条曲线显示 1 小时就是 3600 个点浏览器画起来会卡。通常的做法是前端按像素宽度降采样比如屏幕宽 800 像素就只取 800 个点其余合并。报警展示要区分实时报警和历史报警。实时报警用 WebSocket 推送弹窗或者列表高亮历史报警存数据库按时间范围查询。报警的触发条件可以在网关侧做边缘计算也可以在 Node.js 侧做。我倾向于在 Node.js 侧做因为规则修改方便不用重新配置网关。5.4 移动端适配与多端展示工业现场越来越多地用平板和手机看数据。前端要做响应式或者单独做移动端页面。核心是布局要自适应触摸操作要友好按钮大一点避免误触。多端展示的关键是后端接口统一。PC、平板、手机、大屏都调同一套 HTTP 和 WebSocket 接口前端各自渲染。这样后端只维护一套逻辑前端按设备类型做不同的展示。大屏展示要特别注意分辨率和刷新频率。大屏一般是 1920x1080 或者更高浏览器全屏运行长时间不刷新容易内存泄漏。建议大屏页面定时重载比如每天凌晨自动刷新一次。6. 现场落地踩过的坑与排查经验6.1 网关读不到数据的排查链路网关读不到 PLC 数据是现场最高频的问题。我的排查顺序是这样的第一步确认物理连接。串口的话看接线对不对、终端电阻有没有、波特率等参数是否一致网口的话 ping 一下 PLC 的 IP看通不通。第二步确认协议参数。站号、寄存器地址、数据类型这些一个都不能错。特别是寄存器地址不同 PLC 的地址偏移规则不一样有的从 0 开始有的从 1 开始有的地址要加 40001 这种前缀。这个坑我踩过不止一次。第三步用第三方工具交叉验证。比如用 Modbus Poll 直接连 PLC 读数据如果能读到说明 PLC 和物理链路没问题问题在网关配置如果读不到问题在 PLC 侧或者链路侧。第四步看网关日志。网关一般都有通信日志能看到发送的报文和收到的响应。如果发出去没响应是链路问题如果响应是异常码是地址或参数问题。6.2 MQTT 连接不稳定与消息丢失MQTT 连接不稳定常见原因有几个。一是网络抖动网关和 Broker 之间的网络质量差导致频繁断连。这种情况要检查网络设备或者把reconnectPeriod设短一点让它快速重连。二是 clientId 冲突。两个客户端用了同一个 clientId会互相踢下线表现为反复断连。排查方法是看 Broker 日志会记录哪个 clientId 被踢。三是认证失败。用户名密码错了或者密码文件没生效连接会被拒绝。看 Broker 日志能直接看到认证失败的原因。消息丢失的话先确认 QoS 等级。QoS 0 本来就不保证到达如果业务不能丢数据必须用 QoS 1 或 2。另外要确认订阅的主题有没有写错通配符用对没有。factory_a//realtime和factory_a/#匹配的范围是不一样的。6.3 Node.js 服务的内存与并发问题Node.js 服务跑久了内存涨多半是事件监听器泄漏或者缓存无上限。比如每次 WebSocket 连接都往某个数组里 push断开时没移除数组越来越大。或者用 Map 存最新值但设备删除了 Map 里的条目没清理。排查内存问题可以用process.memoryUsage()定期打印或者用 Chrome DevTools 连上去做堆快照。生产环境建议用 PM2 这类进程管理工具配置内存上限超了自动重启。并发方面Node.js 单进程能扛的连接数是有上限的。如果 WebSocket 客户端超过几千个要考虑多进程或者多机部署前面加负载均衡。MQTT 订阅可以用共享订阅Shared Subscription让多个 Node.js 实例分担消息处理。6.4 断网续传与数据补采工业现场网络不稳定是常态断网期间的数据不能丢。这要靠网关的断网缓存功能。网关检测到 MQTT 断连后把数据存到本地重连后按时间顺序补发。配置的时候要注意缓存容量太小了断网时间长就存不下太大了占网关存储。补发的数据到了 Node.js 侧要按时间戳入库不能按接收时间入库否则历史曲线的时间轴会乱。这一点在写落库逻辑的时候要特别注意时间戳一定用消息体里的采集时间不要用服务端的当前时间。如果网关不支持断网缓存那就要在 Node.js 侧做补偿逻辑比如检测到某个设备的数据有断档主动去网关或者 PLC 补采。这个实现起来复杂能靠网关解决就靠网关解决。7. 几个实际项目中的经验补充7.1 关于 PLC 温度 PID 波动大的处理有朋友问过 PLC 温度 PID 波动温差大的问题这个在采集上云的项目里也常遇到。温度控制本身是 PLC 侧的事但采集上来的曲线能帮你判断问题。如果曲线显示温度在设定值上下大幅振荡通常是 PID 参数没整定好比例带太窄或者积分时间太短。如果曲线显示温度响应很慢是比例带太宽或者积分时间太长。采集系统能做的是把温度曲线、加热输出、设定值三条曲线放在一起对比这样整定 PID 的时候有依据。我一般会在 Web 页面上做一个专门的 PID 调试页面实时显示这三条曲线工程师调参数的时候能立刻看到效果。7.2 多品牌 PLC 混用的地址映射一个厂区里往往有多个品牌的 PLC西门子、三菱、汇川、台达都有。每个品牌的寄存器地址规则不一样如果直接在 Node.js 里处理代码会非常乱。我的做法是在网关侧统一映射。不管底层是什么 PLC网关配置的时候都映射成统一的变量名比如temp_01、motor_01_speed。这样 Node.js 侧拿到的数据格式是一致的不用关心底层是什么 PLC。换 PLC 的时候只改网关配置Node.js 和前端都不用动。这个统一命名的思路本质上是做了一层抽象。工业项目里这种抽象非常重要能大幅降低后期维护成本。7.3 关于 AI 辅助生成 PLC 代码的现状最近 AI 生成 PLC 代码的话题挺热我也试过一些工具。目前的水平是简单的逻辑比如电机启停、定时器、计数器能生成得八九不离十但复杂的工艺逻辑、安全联锁、异常处理还是得靠人。AI 生成的代码可以作为初稿但一定要人工审查特别是安全相关的部分不能直接下载到 PLC 里跑。在采集上云的项目里AI 能帮上忙的地方是生成数据点表的模板、生成 Node.js 的样板代码、生成前端页面的骨架。这些重复性的工作交给 AI能省不少时间。但核心的协议配置、网络规划、异常处理还是得靠经验。7.4 离线环境下的部署注意事项很多工业现场是内网环境服务器不能联网。这种环境下部署 Node.js 服务要注意几点。一是依赖包要提前下载好。在能联网的机器上npm install之后把node_modules整个打包带过去或者用npm pack把依赖打成离线包。二是 Node.js 本身要离线安装。下载对应架构的二进制包解压配置环境变量即可。三是 MQTT Broker 也要离线安装。Mosquitto 的 RPM 包或者二进制包提前准备好。四是时间同步。内网环境如果没有 NTP 服务器各台机器的时间可能不一致导致数据时间戳混乱。建议在内网搭一个 NTP 服务所有设备对时。这套方案我从最早的单个车间试点到现在几个厂区同时跑中间迭代了好几版。最开始用组态软件后来换成网关加 MQTT再后来把 Node.js 服务拆成采集、存储、接口三个模块。每次迭代都是被实际需求推着走的没有一步到位的设计。如果你正准备做类似的项目我的建议是先把最小链路跑通——一台网关、一个 Broker、一个 Node.js 脚本、一个网页能实时看到一个数据点然后再往上加功能。这个最小链路跑通了后面都是量的积累不会再遇到方向性的问题。 PLC数据上云实战：工业网关+MQTT+Node.js搭建Web SCADA
工业现场的数据上云很多人卡在第一步PLC 里的数据怎么稳定、低成本地送到 Web 端。传统做法是买一套组态软件加授权成本高、扩展性差想接个自定义看板或者推给第三方系统处处受限。这两年我陆续做了几个从 PLC 采集到 Web SCADA 展示的完整项目从台达、汇川、西门子 S7-200 SMART 到三菱 FX 系列都碰过最终沉淀出一套相对通用的方案工业智能网关负责现场协议采集MQTT 做消息总线Node.js 做数据接入与 Web 服务。整套链路跑通之后加一个采集点、换一个展示页面成本几乎可以忽略。这篇就把这套方案从选型、搭建到落地的完整过程拆开讲适合有 PLC 基础但没接触过物联网链路的朋友也适合想从传统组态转向 Web SCADA 的工程师参考。1. 为什么放弃传统组态转向网关加 MQTT 加 Node.js1.1 传统上位机方案的三个硬伤先说清楚为什么要换方案不然很容易陷入能用就行的惯性。传统上位机方案通常是 PLC 通过串口或以太网连到一台工控机工控机上跑组态软件组态软件再通过 OPC 或者自有协议把数据给到其他系统。这套东西在单机、单车间场景下没问题但一旦要联网、要多端展示、要对接 MES 或者云平台问题就集中爆发了。第一个硬伤是授权成本与点数绑定。组态软件的点数授权是线性涨价的一个项目几百个点授权费用可能比硬件还贵。而且很多组态软件的外部接口是单独收费的想通过 API 把数据推出去又是一笔钱。第二个硬伤是协议封闭。组态软件采集上来的数据往往只能在自己的生态里流转。想接一个自定义的 Web 看板或者把数据推给第三方的数据分析平台要么买它的接口模块要么做二次开发周期长、依赖厂商。第三个硬伤是部署与运维重。一台工控机放在现场Windows 系统要打补丁、要防病毒、要防断电组态软件升级还可能影响正在跑的项目。现场环境粉尘大、温度高工控机硬盘故障是家常便饭。1.2 网关加 MQTT 加 Node.js 的分工逻辑换成网关加 MQTT 加 Node.js 之后这三者的分工非常清晰各干各擅长的事。工业智能网关负责最底层的协议适配。它向下通过 RS485、RS232、以太网等物理接口连接 PLC、变频器、仪表向上把采集到的数据统一成一种轻量的消息格式。网关的核心价值在于它内置了大量工业协议驱动比如 Modbus RTU、Modbus TCP、西门子 S7 协议、三菱 MC 协议、欧姆龙 FINS 等你不需要自己写协议解析代码配置一下寄存器地址就能读到数据。MQTT负责消息的传输与分发。它是一种发布订阅模式的消息协议特别适合工业场景带宽占用小、支持断线重连、支持 QoS 等级、天然支持一对多分发。网关把数据发布到某个主题任何订阅了这个主题的客户端都能收到Web 服务、手机 App、数据分析程序可以同时订阅互不干扰。Node.js负责数据接入与 Web 服务。它订阅 MQTT 主题把数据存下来内存、时序数据库或者关系库同时对外提供 HTTP 接口和 WebSocket 推送前端页面就能实时刷新。Node.js 的事件驱动模型特别适合这种大量并发连接、低计算量的场景一台普通服务器扛几千个 MQTT 连接和 WebSocket 连接毫无压力。1.3 这套方案适合什么样的项目不是所有项目都适合这套方案我把它适用的边界说清楚避免生搬硬套。适合的场景需要多端展示PC、手机、大屏、需要对接第三方系统、采集点分散在多个车间或厂区、预算有限但要求可扩展、需要做数据留存和分析。不太适合的场景对实时性要求极高毫秒级闭环控制、现场完全没有网络基础设施且不允许布线、项目规模极小就十几个点且永远不扩展。这些场景用传统组态或者本地 HMI 反而更省事。提示网关加 MQTT 加 Node.js 这套链路本质上是把采集和展示解耦。采集端只管把数据发出来展示端只管订阅。这个解耦是整套方案灵活性的来源也是后面所有设计决策的出发点。2. 工业智能网关的选型与现场接线要点2.1 网关选型要看哪几个参数市面上的工业智能网关品牌很多价格从几百到几千不等。选型的时候不要只看价格下面这几个参数直接决定项目能不能顺利落地。参数项说明建议下行协议支持网关能对接的 PLC 和仪表协议至少覆盖 Modbus RTU/TCP西门子、三菱、台达、汇川等主流品牌驱动要齐全上行协议支持网关对外发送数据的协议必须支持 MQTT最好同时支持 HTTP、Modbus TCP 转发的串口数量RS485/RS232 接口数量现场仪表多的话至少 2 路 RS485网口数量以太网接口数量至少 1 路用于连接 PLC 和上行网络采集点数支持的最大采集变量数按实际点数的 1.5 倍预留边缘计算能力是否支持脚本、公式、报警有的话可以做数据预处理减轻服务端压力断网缓存断网时是否缓存数据工业现场网络不稳定这个功能很关键我个人的经验是下行协议驱动的齐全程度比硬件参数更重要。有些网关硬件配置很漂亮但某个品牌的 PLC 驱动写得不好读数据经常超时或者读错地址这种坑非常难排查。选型前最好拿现场实际的 PLC 型号问厂商要一份驱动支持列表确认能读能写。2.2 现场接线与网络规划接线这块看似简单但现场出问题十有八九是接线和网络规划没做好。串口接线要注意 RS485 的 A、B 线不要接反接反了通信不上但不会烧设备排查起来很费时间。多个从站挂在同一条 RS485 总线上时要采用手拉手的方式不要星型分支分支会导致信号反射。总线两端要接终端电阻一般 120 欧姆。波特率、数据位、停止位、校验位这几个参数网关和 PLC 必须完全一致差一个都通不了。网络规划方面如果 PLC 是网口通信网关和 PLC 要在同一个网段。我习惯给网关单独规划一个管理网段和办公网隔离避免办公网的广播风暴影响采集。如果现场有多台网关每台的 IP 要提前规划好做好台账不然后期维护找不到设备。供电方面网关一般用 24V 直流供电要和 PLC 的供电分开走线避免 PLC 启停时的电压波动影响网关。有条件的话给网关配一个小型 UPS断电时能撑几分钟让网关把缓存数据发出去。2.3 网关侧的数据点配置网关配置的核心工作是建立数据点表。所谓数据点表就是把 PLC 里的寄存器地址、数据类型、缩放系数、单位等信息整理成一张表然后在网关的配置界面里逐个录入。以读取西门子 S7-200 SMART 的一个温度值为例假设温度存在 VW100 寄存器里实际值是放大 10 倍的整数比如 256 表示 25.6 摄氏度那么配置大概是这样的变量名temp_01寄存器地址VW100数据类型int16缩放系数0.1单位摄氏度采集周期1000ms这里有个容易忽略的点采集周期不是越短越好。Modbus RTU 是轮询机制如果一条总线上挂了 10 个从站每个从站采集周期都设 100ms那总线根本忙不过来会出现大量超时。合理的做法是按数据变化频率分组变化快的比如电机电流设 500ms 到 1s变化慢的比如温度、液位设 5s 到 10s。注意网关配置完成后一定要用网关自带的调试工具或者 MQTT 客户端先确认数据能正常发出来再去搭后面的服务端。现场排查问题的成本远高于在办公室排查。3. MQTT 服务端的搭建与主题设计3.1 MQTT 服务端选型与安装MQTT 服务端Broker是整个链路的中枢所有数据都经过它转发。选型上开源方案里 Mosquitto 轻量、稳定、资源占用低适合中小规模项目EMQX 功能更全支持集群、规则引擎、Dashboard适合规模较大或者需要做数据桥接的场景。以 Mosquitto 为例在 Linux 服务器上安装非常直接。CentOS 7.9 环境下# 安装 mosquitto yum install -y epel-release yum install -y mosquitto mosquitto-clients # 启动并设置开机自启 systemctl start mosquitto systemctl enable mosquitto # 查看状态 systemctl status mosquitto默认配置下 Mosquitto 只监听本地 1883 端口如果要让网关从外部连进来需要修改配置文件/etc/mosquitto/mosquitto.conf# 监听所有网卡的 1883 端口 listener 1883 0.0.0.0 # 允许匿名连接内网测试用生产环境务必关闭 allow_anonymous true生产环境一定要关闭匿名连接配置用户名密码认证。Mosquitto 的用户管理用mosquitto_passwd命令# 创建密码文件并添加用户 mosquitto_passwd -c /etc/mosquitto/passwd gateway_user # 按提示输入密码 # 再添加一个 Web 服务用的用户 mosquitto_passwd /etc/mosquitto/passwd web_user然后在配置文件里指定密码文件并关闭匿名allow_anonymous false password_file /etc/mosquitto/passwd改完配置记得重启服务并且检查防火墙有没有放行 1883 端口。3.2 主题层级的设计原则MQTT 的主题设计是很多人忽略但影响深远的一件事。主题设计得好后期扩展、权限控制、数据分流都很轻松设计得乱后面想加个功能就得改所有客户端。主题用斜杠分层我一般按项目/厂区/设备类型/设备编号/数据类型这样的层级来设计。举个例子factory_a/workshop_1/plc/plc_001/realtime factory_a/workshop_1/plc/plc_001/alarm factory_a/workshop_1/meter/meter_005/realtime这样设计的好处是订阅的时候可以用通配符灵活匹配。匹配单层#匹配多层。比如factory_a/workshop_1/plc//realtime订阅一号车间所有 PLC 的实时数据factory_a/#订阅 A 厂区所有数据factory_a/workshop_1/plc/plc_001/#订阅某台 PLC 的所有类型数据主题里不要放具体数值数值放在消息体里。主题只用来标识这是什么数据消息体里放数据是多少、什么时间采集的。消息体用 JSON 格式可读性和扩展性都好{ deviceId: plc_001, timestamp: 1735689600000, values: { temp_01: 25.6, pressure_01: 0.85, motor_speed: 1450 } }3.3 QoS 等级与保留消息的取舍MQTT 有三个 QoS 等级很多人不知道该选哪个。简单说QoS 0最多发一次不保证到达。适合高频、可丢失的数据比如实时曲线刷新。QoS 1至少发一次可能重复。适合大多数工业数据采集场景。QoS 2恰好发一次开销最大。适合计费、报警确认这类不能重复不能丢失的场景。工业采集我一般用 QoS 1。因为网关和 Broker 之间的网络相对稳定QoS 1 的开销可以接受而且能保证数据不丢。QoS 2 的四次握手在高频采集下开销太大不划算。保留消息Retained Message是个很实用的特性。当网关把一条消息设为保留消息发布后Broker 会保存这条消息的最后一条任何新订阅该主题的客户端会立刻收到这条消息。这个特性特别适合 Web 页面首次加载时快速拿到当前值不用等下一次采集周期。但保留消息也有坑如果主题设计得太多太细每条都设保留消息Broker 的内存会被大量占用。我的做法是只对当前值这类主题设保留消息历史数据主题不设。3.4 用 MQTT Explorer 做链路验证在正式写 Node.js 代码之前强烈建议先用 MQTT Explorer 这个图形化客户端验证链路。它能连上 Broker订阅主题实时看到消息内容还能看到保留消息和主题树结构。验证步骤很简单打开 MQTT Explorer填入 Broker 地址、端口、用户名密码连接成功后订阅factory_a/#然后看网关有没有数据发过来。如果能看到数据说明网关到 Broker 这一段通了接下来写 Node.js 就只是订阅和存储的事。如果看不到问题就在网关侧或者网络侧先解决这一段。这个分段验证的思路非常重要。整条链路涉及网关、网络、Broker、Node.js、前端多个环节一次性全搭好再调试出了问题根本不知道是哪一段。分段验证每段确认通了再往下走效率高得多。4. Node.js 数据接入服务的实现4.1 Node.js 环境准备与版本选择Node.js 的安装本身不复杂但版本选择有讲究。工业项目我建议用 LTS长期支持版本比如 20.x 或者 22.x 的 LTS。不要用最新的实验版本也不要用太老的版本老版本可能不支持某些新语法和库。Windows 上直接去官网下载安装包一路下一步就行。Linux 上推荐用 NodeSource 的源安装比系统自带的版本新# CentOS 7.9 安装 Node.js 20.x curl -fsSL https://rpm.nodesource.com/setup_20.x | bash - yum install -y nodejs # 验证安装 node -v npm -v如果服务器不能联网需要离线安装那就下载对应的二进制包解压配置环境变量。麒麟 V10 ARM 架构的服务器也是类似思路下载 ARM64 的包。验证是否安装成功除了node -v还可以跑一句node -e console.log(ok)能输出 ok 就说明环境没问题。4.2 用 mqtt.js 订阅网关数据Node.js 里操作 MQTT 最常用的库是mqtt也就是 mqtt.js。先初始化项目并安装依赖mkdir scada-server cd scada-server npm init -y npm install mqtt然后写一个最简的订阅脚本const mqtt require(mqtt); const client mqtt.connect(mqtt://127.0.0.1:1883, { username: web_user, password: your_password, clientId: scada_server_ Math.random().toString(16).slice(2, 8), clean: true, reconnectPeriod: 5000 }); client.on(connect, () { console.log(MQTT connected); client.subscribe(factory_a/#, { qos: 1 }, (err) { if (err) console.error(subscribe failed, err); else console.log(subscribed); }); }); client.on(message, (topic, payload) { try { const data JSON.parse(payload.toString()); console.log(topic, data); // 这里做数据存储和转发 } catch (e) { console.error(parse error, e.message); } }); client.on(error, (err) { console.error(MQTT error, err); });几个关键点说明一下。clientId要保证唯一否则两个客户端用同一个 clientId 会互相踢下线。reconnectPeriod设置自动重连间隔网络抖动时能自动恢复。clean: true表示不保留会话状态如果希望断线重连后还能收到离线期间的消息要设成false并配合固定的 clientId。4.3 数据落库内存、时序库还是关系库数据订阅到之后存哪里是个关键决策。三种选择各有适用场景。内存存储最简单用一个 Map 存每个设备的最新值Web 页面通过 WebSocket 拿实时数据。优点是快缺点是重启就丢且不能查历史。适合只做实时监控、不需要历史的场景。时序数据库比如 InfluxDB、TDengine专门为时间序列数据设计写入快、压缩率高、按时间范围查询效率高。适合需要存历史曲线、做趋势分析的场景。TDengine 对工业场景支持很好还有免费的社区版。关系数据库比如 MySQL、PostgreSQL适合需要和业务数据关联的场景比如把采集数据和工单、设备台账关联起来。但高频写入对关系库压力较大一般会做降采样比如原始数据存时序库分钟级聚合数据存关系库。我实际项目里最常见的组合是内存存最新值 时序库存原始数据 关系库存聚合和业务数据。三者各司其职查询的时候按需取。4.4 对外提供 HTTP 接口与 WebSocket 推送Node.js 服务订阅到数据后要对外提供两种接口一种是 HTTP 接口用于查询历史数据、设备列表、配置信息另一种是 WebSocket用于实时推送。HTTP 接口用 Express 或者 Fastify 都很方便。WebSocket 用ws库。下面是一个把 MQTT 数据和 WebSocket 打通的最小示例const express require(express); const http require(http); const WebSocket require(ws); const mqtt require(mqtt); const app express(); const server http.createServer(app); const wss new WebSocket.Server({ server }); // 存最新值 const latestValues new Map(); // WebSocket 连接管理 wss.on(connection, (ws) { console.log(ws client connected); // 连接建立时先把当前所有最新值推一遍 ws.send(JSON.stringify({ type: snapshot, data: Object.fromEntries(latestValues) })); }); // MQTT 订阅 const client mqtt.connect(mqtt://127.0.0.1:1883, { username: web_user, password: your_password }); client.on(connect, () { client.subscribe(factory_a/#, { qos: 1 }); }); client.on(message, (topic, payload) { const data JSON.parse(payload.toString()); latestValues.set(topic, data); // 广播给所有 WebSocket 客户端 const msg JSON.stringify({ type: update, topic, data }); wss.clients.forEach((ws) { if (ws.readyState WebSocket.OPEN) ws.send(msg); }); }); // HTTP 接口 app.get(/api/latest, (req, res) { res.json(Object.fromEntries(latestValues)); }); server.listen(3000, () console.log(server on 3000));这段代码虽然简单但已经包含了完整的核心逻辑订阅、缓存、广播、查询。实际项目里再往上加认证、日志、错误处理、数据落库即可。提示WebSocket 广播的时候要注意如果客户端很多逐个 send 会有性能问题。生产环境可以用发布订阅模式在服务内部再做一层分发或者用 Socket.IO 这类封装好的库。5. 从数据到画面Web SCADA 前端的实现思路5.1 实时数据绑定的基本模式前端拿到 WebSocket 推来的数据后要把它绑定到画面上。最朴素的做法是每个数据点对应一个 DOM 元素收到更新就改这个元素的文本或者样式。但工业画面往往有几百个点逐个操作 DOM 性能很差。更好的做法是数据驱动视图。用 Vue 或者 React 这类框架把数据放在响应式对象里视图自动更新。比如用 Vue// 数据存储 const state reactive({ devices: {} }); // WebSocket 收到消息后更新 ws.onmessage (e) { const msg JSON.parse(e.data); if (msg.type update) { state.devices[msg.topic] msg.data; } };模板里直接绑定state.devices[factory_a/workshop_1/plc/plc_001/realtime].values.temp_01数据一变视图就变不用手动操作 DOM。5.2 用 SVG 或 Canvas 绘制工艺画面Web SCADA 的画面通常包括设备图形、管道、仪表盘、趋势曲线。绘制方式有两种主流选择SVG 和 Canvas。SVG是矢量图形每个图形元素都是 DOM 节点可以用 CSS 和 JavaScript 直接操作适合画面元素不多、需要交互点击、悬停的场景。工艺流程图、设备状态图用 SVG 很合适。Canvas是位图绘制性能好适合元素非常多或者需要高频重绘的场景比如实时趋势曲线、大量数据点的散点图。但 Canvas 里的元素不是 DOM交互要自己算坐标。实际项目里经常混用工艺画面用 SVG趋势曲线用 Canvas或者用 ECharts 这类图表库它底层用 Canvas。5.3 趋势曲线与报警展示趋势曲线是 Web SCADA 的刚需。实现方式有两种一种是前端定时从 HTTP 接口拉历史数据用 ECharts 画出来另一种是 WebSocket 推实时数据前端维护一个滑动窗口不断往曲线里追加点。实时曲线要注意数据降采样。如果采集周期是 1 秒一条曲线显示 1 小时就是 3600 个点浏览器画起来会卡。通常的做法是前端按像素宽度降采样比如屏幕宽 800 像素就只取 800 个点其余合并。报警展示要区分实时报警和历史报警。实时报警用 WebSocket 推送弹窗或者列表高亮历史报警存数据库按时间范围查询。报警的触发条件可以在网关侧做边缘计算也可以在 Node.js 侧做。我倾向于在 Node.js 侧做因为规则修改方便不用重新配置网关。5.4 移动端适配与多端展示工业现场越来越多地用平板和手机看数据。前端要做响应式或者单独做移动端页面。核心是布局要自适应触摸操作要友好按钮大一点避免误触。多端展示的关键是后端接口统一。PC、平板、手机、大屏都调同一套 HTTP 和 WebSocket 接口前端各自渲染。这样后端只维护一套逻辑前端按设备类型做不同的展示。大屏展示要特别注意分辨率和刷新频率。大屏一般是 1920x1080 或者更高浏览器全屏运行长时间不刷新容易内存泄漏。建议大屏页面定时重载比如每天凌晨自动刷新一次。6. 现场落地踩过的坑与排查经验6.1 网关读不到数据的排查链路网关读不到 PLC 数据是现场最高频的问题。我的排查顺序是这样的第一步确认物理连接。串口的话看接线对不对、终端电阻有没有、波特率等参数是否一致网口的话 ping 一下 PLC 的 IP看通不通。第二步确认协议参数。站号、寄存器地址、数据类型这些一个都不能错。特别是寄存器地址不同 PLC 的地址偏移规则不一样有的从 0 开始有的从 1 开始有的地址要加 40001 这种前缀。这个坑我踩过不止一次。第三步用第三方工具交叉验证。比如用 Modbus Poll 直接连 PLC 读数据如果能读到说明 PLC 和物理链路没问题问题在网关配置如果读不到问题在 PLC 侧或者链路侧。第四步看网关日志。网关一般都有通信日志能看到发送的报文和收到的响应。如果发出去没响应是链路问题如果响应是异常码是地址或参数问题。6.2 MQTT 连接不稳定与消息丢失MQTT 连接不稳定常见原因有几个。一是网络抖动网关和 Broker 之间的网络质量差导致频繁断连。这种情况要检查网络设备或者把reconnectPeriod设短一点让它快速重连。二是 clientId 冲突。两个客户端用了同一个 clientId会互相踢下线表现为反复断连。排查方法是看 Broker 日志会记录哪个 clientId 被踢。三是认证失败。用户名密码错了或者密码文件没生效连接会被拒绝。看 Broker 日志能直接看到认证失败的原因。消息丢失的话先确认 QoS 等级。QoS 0 本来就不保证到达如果业务不能丢数据必须用 QoS 1 或 2。另外要确认订阅的主题有没有写错通配符用对没有。factory_a//realtime和factory_a/#匹配的范围是不一样的。6.3 Node.js 服务的内存与并发问题Node.js 服务跑久了内存涨多半是事件监听器泄漏或者缓存无上限。比如每次 WebSocket 连接都往某个数组里 push断开时没移除数组越来越大。或者用 Map 存最新值但设备删除了 Map 里的条目没清理。排查内存问题可以用process.memoryUsage()定期打印或者用 Chrome DevTools 连上去做堆快照。生产环境建议用 PM2 这类进程管理工具配置内存上限超了自动重启。并发方面Node.js 单进程能扛的连接数是有上限的。如果 WebSocket 客户端超过几千个要考虑多进程或者多机部署前面加负载均衡。MQTT 订阅可以用共享订阅Shared Subscription让多个 Node.js 实例分担消息处理。6.4 断网续传与数据补采工业现场网络不稳定是常态断网期间的数据不能丢。这要靠网关的断网缓存功能。网关检测到 MQTT 断连后把数据存到本地重连后按时间顺序补发。配置的时候要注意缓存容量太小了断网时间长就存不下太大了占网关存储。补发的数据到了 Node.js 侧要按时间戳入库不能按接收时间入库否则历史曲线的时间轴会乱。这一点在写落库逻辑的时候要特别注意时间戳一定用消息体里的采集时间不要用服务端的当前时间。如果网关不支持断网缓存那就要在 Node.js 侧做补偿逻辑比如检测到某个设备的数据有断档主动去网关或者 PLC 补采。这个实现起来复杂能靠网关解决就靠网关解决。7. 几个实际项目中的经验补充7.1 关于 PLC 温度 PID 波动大的处理有朋友问过 PLC 温度 PID 波动温差大的问题这个在采集上云的项目里也常遇到。温度控制本身是 PLC 侧的事但采集上来的曲线能帮你判断问题。如果曲线显示温度在设定值上下大幅振荡通常是 PID 参数没整定好比例带太窄或者积分时间太短。如果曲线显示温度响应很慢是比例带太宽或者积分时间太长。采集系统能做的是把温度曲线、加热输出、设定值三条曲线放在一起对比这样整定 PID 的时候有依据。我一般会在 Web 页面上做一个专门的 PID 调试页面实时显示这三条曲线工程师调参数的时候能立刻看到效果。7.2 多品牌 PLC 混用的地址映射一个厂区里往往有多个品牌的 PLC西门子、三菱、汇川、台达都有。每个品牌的寄存器地址规则不一样如果直接在 Node.js 里处理代码会非常乱。我的做法是在网关侧统一映射。不管底层是什么 PLC网关配置的时候都映射成统一的变量名比如temp_01、motor_01_speed。这样 Node.js 侧拿到的数据格式是一致的不用关心底层是什么 PLC。换 PLC 的时候只改网关配置Node.js 和前端都不用动。这个统一命名的思路本质上是做了一层抽象。工业项目里这种抽象非常重要能大幅降低后期维护成本。7.3 关于 AI 辅助生成 PLC 代码的现状最近 AI 生成 PLC 代码的话题挺热我也试过一些工具。目前的水平是简单的逻辑比如电机启停、定时器、计数器能生成得八九不离十但复杂的工艺逻辑、安全联锁、异常处理还是得靠人。AI 生成的代码可以作为初稿但一定要人工审查特别是安全相关的部分不能直接下载到 PLC 里跑。在采集上云的项目里AI 能帮上忙的地方是生成数据点表的模板、生成 Node.js 的样板代码、生成前端页面的骨架。这些重复性的工作交给 AI能省不少时间。但核心的协议配置、网络规划、异常处理还是得靠经验。7.4 离线环境下的部署注意事项很多工业现场是内网环境服务器不能联网。这种环境下部署 Node.js 服务要注意几点。一是依赖包要提前下载好。在能联网的机器上npm install之后把node_modules整个打包带过去或者用npm pack把依赖打成离线包。二是 Node.js 本身要离线安装。下载对应架构的二进制包解压配置环境变量即可。三是 MQTT Broker 也要离线安装。Mosquitto 的 RPM 包或者二进制包提前准备好。四是时间同步。内网环境如果没有 NTP 服务器各台机器的时间可能不一致导致数据时间戳混乱。建议在内网搭一个 NTP 服务所有设备对时。这套方案我从最早的单个车间试点到现在几个厂区同时跑中间迭代了好几版。最开始用组态软件后来换成网关加 MQTT再后来把 Node.js 服务拆成采集、存储、接口三个模块。每次迭代都是被实际需求推着走的没有一步到位的设计。如果你正准备做类似的项目我的建议是先把最小链路跑通——一台网关、一个 Broker、一个 Node.js 脚本、一个网页能实时看到一个数据点然后再往上加功能。这个最小链路跑通了后面都是量的积累不会再遇到方向性的问题。