1. 工业现场老旧设备加装Modbus转MQTT采集方案详解1.1 为什么老旧设备还要继续用我在工厂做设备数据采集断断续续有七八年了接触最多的场景就是车间里一堆用了十几年的老设备PLC、温控表、变频器、电表清一色RS485或者RS232串口跑的都是Modbus RTU。老板突然说要做数字化看板、要上云、要远程监控你一看这些设备头都大了——它们根本不知道什么叫网络什么叫JSON。但你又不能把这些设备全换掉。一台进口注塑机的控制器换掉可能十几万一条产线停一天损失几十万。所以最务实的做法就是在设备旁边加一个采集网关把Modbus的数据读出来转成MQTT发到服务器。设备还是那些设备但数据活了。这个方案适合谁看如果你是工厂的电气工程师、自动化集成商的技术人员、或者做工业物联网的开发者手头正好有类似需求那这篇内容应该能帮你少走不少弯路。我会从方案设计、硬件选型、协议转换逻辑、实操配置到踩坑经验完整地讲一遍。1.2 整体方案架构长什么样先把这个方案的全貌说清楚。整个链路其实就四层第一层是现场设备层。各种支持Modbus RTU/TCP的仪表、PLC、传感器。它们通过RS485总线或者以太网口对外提供数据。第二层是采集网关层。这是核心。网关通过串口或者网口跟设备通信按照Modbus协议把寄存器数据读上来然后在网关内部做数据映射和格式转换最后通过MQTT协议发布到服务器。网关可以是专用的工业网关硬件也可以是一台工控机跑软件。第三层是MQTT Broker层。也就是MQTT服务器负责消息的接收和分发。可以部署在厂内服务器上也可以放在云端。常见的选择有EMQX、Mosquitto、HiveMQ等。第四层是应用层。数据库、SCADA系统、看板、报警系统等等通过订阅MQTT主题拿到数据。这个架构的好处是解耦。设备侧不用动应用侧也不用关心底层是什么协议中间靠MQTT这个统一的消息总线衔接。你以后要加新设备只要网关支持接入方式是一样的。注意很多人一上来就想把Modbus TCP设备直接接MQTT觉得省掉网关。但Modbus TCP设备本身不具备MQTT能力你还是需要一个中间件来做协议转换。除非设备本身支持MQTT否则网关这层省不掉。2. 核心细节解析与实操要点2.1 Modbus协议的关键概念回顾在动手之前有几个Modbus的核心概念必须搞清楚不然后面配置的时候会一头雾水。寄存器类型。Modbus有四种数据类型线圈Coil、离散输入Discrete Input、保持寄存器Holding Register、输入寄存器Input Register。线圈和离散输入是位数据一个地址存一个布尔值保持寄存器和输入寄存器是16位字数据一个地址存一个16位整数。实际项目中保持寄存器用得最多因为大部分模拟量、参数值都放在这里。站号Slave ID。一条RS485总线上可以挂多个设备每个设备有一个唯一的站号范围1到247。网关轮询的时候靠站号来区分跟谁说话。功能码。读线圈用01读离散输入用02读保持寄存器用03读输入寄存器用04写单个寄存器用06写多个寄存器用16。采集场景下最常用的就是03和04。寄存器地址。这里有个坑Modbus协议报文里的地址是从0开始的但很多设备手册上写的地址是从1开始的。比如手册上写“温度值在40001寄存器”实际报文里你要用地址0去读。这个偏移问题几乎每个新手都会踩。数据格式。一个寄存器是16位但实际数据可能是32位浮点数、32位整数、甚至64位。32位数据要占两个连续寄存器这时候就涉及字节序和字序的问题。不同厂家的设备排列方式可能不一样有大端、小端、字交换等各种组合。这个后面实操部分会详细讲。2.2 MQTT协议的核心机制MQTT是一个基于发布/订阅模式的轻量级消息协议特别适合工业场景因为它的报文开销小网络不稳定的时候也能工作。Broker。消息中转站所有客户端都连到它上面。发布者把消息发给BrokerBroker再转发给订阅者。工业场景常用的Broker有EMQX和Mosquitto前者功能更全后者更轻量。Topic。主题类似消息的地址。发布者往某个Topic发消息订阅者订阅这个Topic就能收到。Topic用斜杠分层比如factory/line1/machine3/temperature。设计Topic的时候要有层次感方便后续做权限控制和数据路由。QoS等级。QoS 0是最多一次发出去就不管了QoS 1是至少一次保证到达但可能重复QoS 2是恰好一次保证不重复但开销大。工业采集场景一般用QoS 1就够了因为数据采集允许偶尔重复但不能丢。Keep Alive和遗嘱消息。Keep Alive是心跳间隔客户端定期给Broker发心跳包证明自己还活着。遗嘱消息是客户端异常断开时Broker自动发布的最后一条消息可以用来做设备离线告警。Clean Session。这个参数决定Broker是否保留客户端的会话状态。如果设为false客户端断线重连后还能收到断线期间订阅的消息。对于采集网关一般设为false避免网络抖动导致数据丢失。2.3 网关选型硬件还是软件这是方案设计阶段最重要的决策之一。我两种都用过各有适用场景。专用工业网关。比如有人用钡铼、华辰智通、映翰通这些品牌的网关。优点是开箱即用配置界面友好支持多种PLC协议稳定性好工作温度范围宽直接导轨安装。缺点是灵活性差遇到非标协议或者特殊数据格式可能搞不定。价格从几百到几千不等。工控机软件方案。用一台低功耗工控机或者树莓派跑Node-RED、Python脚本或者专门的采集软件。优点是极其灵活想怎么处理数据都行成本也可控。缺点是需要自己维护系统稳定性取决于你的代码质量而且要做好看门狗和自动重启机制。我的建议是如果设备种类少、数据格式标准、预算充足直接上专用网关省心。如果设备种类多、数据格式奇葩、需要做边缘计算比如数据过滤、聚合、告警判断那用工控机方案更合适。对比维度专用工业网关工控机软件部署难度低配置即用中需要装系统配环境灵活性低受限于固件功能高想怎么改就怎么改稳定性高工业级设计取决于硬件和代码质量成本500-5000元300-2000元边缘计算能力有限强维护成本低中高2.4 数据映射与格式转换的核心逻辑这是整个方案里最容易出问题的环节。网关读上来的Modbus数据是一堆16位整数但你要发给MQTT的数据得是有意义的JSON。中间这个转换过程需要处理好几个问题。数据类型转换。比如温度值设备手册说它是32位浮点数存在寄存器40001和40002。你读上来两个16位整数需要把它们拼成一个32位浮点数。拼接的时候要注意字节序。常见的有ABCD大端、CDAB字交换、BADC字节交换、DCBA小端四种排列。量纲转换。很多设备传的是原始值比如温度传的是实际值乘以10你读到253实际是25.3度。这个缩放系数在配置的时候要设对。数据有效性判断。设备可能返回异常值比如65535表示传感器故障。你需要在网关侧做判断异常值不要往MQTT发或者发一个带质量戳的数据。JSON格式化。最终发给MQTT的数据建议用JSON格式可读性好应用侧解析方便。比如{ deviceId: machine3, timestamp: 1712345678000, data: { temperature: 25.3, pressure: 0.85, status: running } }提示时间戳建议用毫秒级Unix时间戳应用侧处理起来最方便。如果网关没有RTC可以通过NTP同步时间或者让Broker侧打时间戳。3. 实操过程与核心环节实现3.1 现场设备摸底与Modbus地址表整理动手之前先把现场设备的Modbus通信手册找齐。没有手册的话用Modbus Poll或者Modbus Slave这类调试工具去扫。我一般会整理一张表包含以下信息设备名称和站号通信参数波特率、数据位、停止位、校验位需要采集的寄存器地址、数据类型、量纲系数、单位读写权限只读还是可写这张表是整个项目的基石后面网关配置全靠它。我见过太多项目因为地址表没整理清楚调试的时候来回折腾。通信参数这块RS485总线上所有设备的波特率、数据位、停止位、校验位必须一致否则通信不上。常见配置是9600-8-N-1或者19200-8-E-1。站号不能重复。3.2 网关硬件接线与网络配置以RS485为例接线就两根线A接AB接B。但实际现场经常遇到A和B接反的情况通信不上。这时候把两根线对调一下试试。另外总线两端要接120欧姆终端电阻尤其是通信距离超过50米或者波特率较高的时候。网关的供电一般是DC 12V或24V从现场开关电源取电。网络方面如果走有线直接插网线如果走无线插4G模块或者连WiFi。我建议工业现场优先走有线稳定性好。实在不方便布线再用4G。网关的IP地址要跟服务器或者Broker在一个网段或者能路由到。如果Broker在云端网关需要能访问外网。3.3 Modbus轮询配置实操以常见的工业网关配置界面为例轮询配置一般包含以下参数轮询周期。每个设备多久读一次。这个要根据数据变化频率来定。温度这种慢变量5秒读一次够了电流、转速这种快变量可能500毫秒读一次。但轮询周期太短会加重总线负载一条485总线上挂的设备越多每个设备的轮询间隔就越长。超时时间。等设备响应的最长时间。一般设300-1000毫秒。设太短容易误判超时设太长会拖慢整体轮询。重试次数。通信失败后重试几次。一般设2-3次。重试太多会阻塞后续设备的轮询。寄存器读取块。把连续的寄存器合并成一个读取请求减少通信次数。比如你要读40001到40010这10个寄存器一次读上来比读10次效率高得多。但要注意有些设备不支持跨寄存器块读取或者块太大会返回异常。配置示例以某网关的JSON配置为例{ pollGroups: [ { name: temperature_meter, slaveId: 1, functionCode: 3, startAddress: 0, quantity: 10, interval: 5000, timeout: 500, retries: 2 } ] }3.4 数据转换与MQTT发布配置读上来的数据要经过转换才能发MQTT。转换规则一般在网关的“数据映射”或者“点表”里配置。以温度为例假设寄存器0和1组成一个32位浮点数字节序是CDAB量纲系数是0.1单位摄氏度。配置大概是这样的{ dataPoints: [ { name: temperature, address: 0, dataType: float32, byteOrder: CDAB, scale: 0.1, unit: ℃, deadband: 0.5 } ] }deadband是死区意思是变化量小于0.5度就不发MQTT减少无效数据。这个在采集点很多的时候特别有用能大幅降低MQTT消息量。MQTT发布配置包含Broker地址、端口、客户端ID、用户名密码、Topic、QoS等级。Topic设计建议包含设备层级比如factory/workshop1/line2/machine3/data客户端ID要唯一建议用网关序列号或者设备ID避免多个网关用同一个ID导致互相踢下线。3.5 MQTT Broker搭建与验证如果Broker部署在厂内可以用EMQX或者Mosquitto。EMQX有Web管理界面配置方便支持集群适合中大型项目。Mosquitto更轻量适合小规模。以Mosquitto为例Ubuntu上安装sudo apt update sudo apt install mosquitto mosquitto-clients默认配置监听1883端口允许匿名访问。生产环境要改配置文件开启认证# /etc/mosquitto/conf.d/default.conf allow_anonymous false password_file /etc/mosquitto/passwd创建用户sudo mosquitto_passwd -c /etc/mosquitto/passwd gateway_user重启服务sudo systemctl restart mosquitto验证的话开两个终端。一个订阅mosquitto_sub -h localhost -t factory/# -u gateway_user -P yourpassword -v另一个发布mosquitto_pub -h localhost -t factory/test -m hello -u gateway_user -P yourpassword订阅端能收到消息就说明Broker工作正常。3.6 端到端联调与数据验证网关配置好之后先别急着接应用侧。用MQTT客户端工具比如MQTTX、MQTT Explorer订阅网关发布的Topic看数据有没有正常上来。检查几个点数据值对不对。跟设备面板上显示的值对比看有没有量纲错误。数据更新频率对不对。看是不是按配置的轮询周期在更新。数据格式对不对。JSON结构是否符合预期。断线重连是否正常。把网关网线拔了再插上看能不能自动恢复。我一般会连续观察至少24小时确认没有偶发性的通信中断或者数据异常。工业现场电磁干扰大有些问题不是一下子能暴露出来的。4. 常见问题与排查技巧实录4.1 Modbus通信不上的排查思路这是最高频的问题。我一般按以下顺序排查第一步检查物理层。RS485的A、B线有没有接反终端电阻有没有接线缆有没有断。用万用表量一下A、B之间的电压正常应该在1-5V之间波动。第二步检查通信参数。波特率、数据位、停止位、校验位是否跟设备一致。站号是否对。这些参数错一个就通信不上。第三步用调试工具单独测试。把网关断开用电脑加USB转485转换器跑Modbus Poll直接连设备。如果能通说明设备没问题问题在网关配置如果不通说明设备或者线路有问题。第四步检查寄存器地址。确认地址偏移有没有搞错功能码对不对。有些设备只支持03不支持04或者反过来。第五步看超时和重试设置。超时太短可能导致误判重试次数太少可能错过响应。4.2 数据值不对的常见原因数据读上来了但值不对这种情况也很常见。原因一般有这几个字节序问题。32位数据的高低字顺序搞反了。比如实际值是25.3你读出来是1.6e-38这种离谱的数基本就是字节序问题。把ABCD改成CDAB试试。量纲系数问题。设备传的是原始值你没做缩放。比如读到253实际是25.3度你忘了乘0.1。地址偏移问题。手册上写40001你用了地址1去读实际应该用地址0。读出来的值可能是隔壁寄存器的。数据类型问题。设备传的是有符号整数你按无符号解析了。比如-10度无符号解析出来是65526。寄存器合并问题。32位数据占了两个寄存器你只读了一个或者两个寄存器的顺序搞反了。排查的时候我一般会先把原始值读出来不做任何转换然后手动算一遍确认转换逻辑对不对。4.3 MQTT消息丢失或重复消息丢失。先检查QoS等级QoS 0是不保证到达的改成QoS 1。然后检查Clean Session设置如果设为true断线期间的消息会丢失。还要检查Broker的持久化配置有些Broker默认不持久化消息。消息重复。QoS 1是至少一次允许重复。如果应用侧对重复敏感要么用QoS 2要么在应用侧做去重。去重可以用消息ID或者时间戳。消息延迟大。检查网络状况尤其是4G网络延迟波动大。另外检查Broker的负载连接数太多或者消息量太大可能导致处理不过来。4.4 网关频繁掉线工业现场网关掉线的原因很多我遇到过的有供电不稳。开关电源质量差或者跟大功率设备共用电源电压波动导致网关重启。网络不稳定。4G信号弱或者网线接触不良。网关过热。夏天车间温度高网关散热不好CPU降频或者死机。看门狗没启用。网关死机后不会自动重启。Broker侧踢下线。多个网关用了同一个客户端ID。解决办法用质量好的开关电源网关单独供电4G信号弱就加天线或者换有线网关安装在通风位置启用看门狗确保客户端ID唯一。4.5 常见问题速查表问题现象可能原因排查方法解决方案Modbus通信不上接线错误、参数不匹配、站号冲突用调试工具单独测试检查A/B线、统一通信参数、修改站号数据值离谱字节序错误、量纲未转换读原始值手动计算调整字节序、添加缩放系数数据不更新轮询周期太长、死区设置过大检查配置缩短轮询周期、调整死区MQTT消息丢失QoS 0、Clean Session true检查MQTT配置改用QoS 1、Clean Session false网关频繁掉线供电不稳、网络差、过热检查电源、信号、温度单独供电、改善网络、加强散热Broker连接失败地址端口错误、认证失败用MQTT客户端测试检查Broker地址、用户名密码4.6 几个我踩过的坑坑一忽略总线负载。一条485总线上挂了20个设备每个设备轮询周期设1秒结果总线根本忙不过来大量超时。后来把慢变量设备的轮询周期改成10秒问题解决。RS485总线的理论最大负载是32个单位负载实际建议不超过16个设备而且轮询周期要合理分配。坑二字节序想当然。以为所有设备都是大端结果遇到一个设备是字交换的调了半天。后来养成习惯拿到新设备先用调试工具读原始值确认字节序再配置。坑三MQTT Topic设计太随意。一开始用data1、data2这种Topic后来设备多了完全分不清。后来改成层级结构应用侧订阅也方便。坑四没做数据缓存。网络中断的时候网关读到的数据直接丢了。后来在网关侧加了本地缓存网络恢复后补发数据完整性好很多。坑五忽略时间同步。网关没有RTC重启后时间归零发出去的数据时间戳全是错的。后来配了NTP或者让Broker侧统一打时间戳。5. 边缘计算能力的扩展思路5.1 为什么要在网关侧做计算数据全部传到服务器再处理有两个问题一是网络带宽和服务器负载压力大二是实时性差。有些场景需要在网关侧就做判断比如设备异常立即停机等数据传到服务器再下发指令就来不及了。边缘计算在采集网关上的典型应用包括数据过滤只发变化的数据、数据聚合多个寄存器的值算出一个综合指标、阈值告警超过阈值直接发告警消息、协议转换Modbus转OPC UA或者其它协议。5.2 用Node-RED做边缘计算如果网关是工控机方案Node-RED是个很好的选择。它用拖拽的方式编排数据流支持Modbus和MQTT节点还能写JavaScript函数做复杂逻辑。一个典型的Node-RED流是这样的Modbus读节点 - 数据转换函数 - 阈值判断 - MQTT发布节点。如果超过阈值同时触发告警节点。// 数据转换函数示例 var temp msg.payload.temperature; var pressure msg.payload.pressure; // 量纲转换 temp temp * 0.1; pressure pressure * 0.01; // 阈值判断 var alarm false; if (temp 80 || pressure 1.5) { alarm true; } msg.payload { temperature: temp, pressure: pressure, alarm: alarm, timestamp: Date.now() }; return msg;5.3 数据缓存与断点续传网络不稳定的时候网关侧的数据缓存很重要。我一般用两种方式内存缓存。简单但网关重启就丢了。适合网络短暂中断的场景。本地数据库缓存。用SQLite或者文件存储网关重启也不丢。网络恢复后按时间顺序补发。适合网络长时间中断的场景。补发的时候要注意数据可能已经过期了应用侧要能处理历史数据。我一般会在消息里加一个cached标记应用侧根据这个标记决定是实时处理还是归档。6. 方案落地后的运维经验6.1 监控网关自身状态网关本身也是设备也会出问题。我一般会让网关定期发布自己的状态信息包括CPU使用率、内存占用、网络状态、Modbus通信成功率等。这些数据发到一个单独的Topic比如factory/gateway/status应用侧做监控。如果Modbus通信成功率低于95%或者网关离线超过一定时间就触发告警。这样能在问题影响生产之前就发现。6.2 配置备份与版本管理网关配置改来改去很容易改乱。我习惯每次修改前先备份配置文件改完之后记录改了什么、为什么改。如果网关支持配置导出定期导出存档。出问题的时候可以快速回滚。6.3 安全加固工业现场的安全越来越重要。几个基本措施MQTT启用认证不要用匿名访问。用TLS加密MQTT通信防止数据被窃听。网关的管理界面改默认密码限制访问IP。Modbus侧如果设备支持启用写保护防止误写。注意TLS加密会增加网关的CPU负载低端网关可能扛不住。如果网关性能有限至少要在网络层做隔离把采集网络和办公网络分开。6.4 扩展性考虑一开始可能只采集几个设备后面会越来越多。所以方案设计的时候要留余量网关的串口数量要够或者支持串口扩展。MQTT Topic设计要有层次方便后续添加新设备。Broker的容量要够连接数和消息吞吐量要留余量。应用侧的数据模型要能灵活扩展不要写死字段。我个人在实际操作中的体会是工业采集项目最难的不是技术本身而是现场的各种意外情况。设备手册找不到、通信参数对不上、电磁干扰导致偶发故障、网络时通时断这些才是真正消耗时间的地方。所以方案设计要尽量简单可靠不要追求花哨的功能。能稳定跑起来、数据准确、维护方便就是好方案。最后再分享一个小技巧调试的时候我习惯在网关和Broker之间加一个MQTT客户端做“旁路监听”实时看网关发了什么数据。这样排查问题的时候能快速定位是网关侧的问题还是应用侧的问题。这个习惯帮我省了很多扯皮的时间。
