干了这些年工业数采项目我越来越确信一件事老工厂里最有价值的数据恰恰掌握在那些连网口都没有的老古董设备手里。几年前接手一个汽车零部件车间的数采改造现场二十多台设备一部分是走Modbus RTU的老PLC和智能仪表一部分是已经上了OPC-UA的新设备还有几台关键设备压根不允许停机接线。客户的要求很直接不能影响生产不能改设备程序数据要实时上传到MES而且车间网络不稳定断网不能丢数据。这个项目就是一次典型的工业遗留设备非侵入式数采架构实战核心是用边缘适配网关统一接入Modbus和OPC-UA在边缘侧做时序数据差分压缩再把网络断连时的自愈机制做扎实。这篇文章想把整个方案的设计思路、踩坑过程、关键代码和调试经验完整记录下来给正在做类似产线数据采集项目的朋友一个可复用的参考。1. 为什么非要非侵入式遗留设备数采的真实痛点1.1 改造式采集的代价停产、风险、权限最开始做方案时我们也考虑过最直接的做法给每台老设备加通信模块或者直接改PLC程序加数据块上传。但现场评估下来这条路基本走不通。第一是停产成本。产线是两班倒停产一小时损失以万计甲方根本不会给你窗口期去停线改造。第二是风险。老设备的PLC程序大多没有备份厂家工程师早就不在了改程序一旦出问题整个工段都得停摆。第三是权限问题。很多设备的控制权在设备供应商手里生产过程参数和技术参数混在同一个程序里甲方想采数据但不想让供应商介入供应商也不愿意开放底层程序。所以非侵入式在这个项目里不是技术选型而是硬性约束。数据采集设备必须像医院的监护仪一样贴在设备旁边只看不动不改变设备本身的任何运行状态。1.2 非侵入式的三项基本原则我总结出三条原则后来的项目也一直沿用不动设备程序不修改PLC梯形图、不下载新固件、不更改设备配置。不占用控制总线和通信端口如果设备只有一路RS485口且在跑Modbus RTU采集端只能通过监听/旁路或者主站轮询方式接入但要考虑总线负载不能让采集影响原系统通信。不干扰原协议交互采集端相对于原系统来说要么是被动监听要么是一个经过评估的额外主站心跳、超时、退避都要保守设置。这三条原则写进方案后甲方才松口让我们动工。后来事实证明很多看似顺手的操作比如改设备IP、动寄存器地址最后都可能变成背锅现场。1.3 项目目标一套网关通吃Modbus和OPC-UA明确了非侵入约束后需求就收敛为一个边缘适配网关这个网关需要对下通过RS485/RS232/以太网接入Modbus RTU/TCP从站通过以太网以OPC-UA Client方式接入新设备。对上通过MQTT或HTTP将统一格式的数据推到MES/云端。本地具备环形缓存、断网续传、边缘压缩能力。运维能远程查看点位状态、网关日志、网络质量。选型阶段我对比了不少现成协议转换网关但最终决定自研边缘采集服务跑在一台工业ARM主机上。原因后面细说简单讲就是现成网关大多只做协议转换压缩和断网自愈能力太弱而且调试起来像黑盒出了问题连日志都拿不到。2. 边缘适配网关的硬件选型与接口拆解2.1 从RS485到以太网接口形态怎么定现场设备通信接口大概是这样的设备类型数量通信接口协议备注老式温控仪表6RS485Modbus RTU9600bps, 8N1老PLC国产5RS485/RS232Modbus RTU从站1个口跑控制1个口空闲电子压力表4RS485Modbus RTU轮询地址1-10新设备控制器8以太网OPC-UA已组网可给独立网段变频器3RS485Modbus RTU只读运行频率和电流接口形态很清晰一路或多路RS485接入Modbus RTU设备以太网口接入OPC-UA设备。这里有个容易忽略的细节RS485总线上多半已经有了PLC主站在跑轮询我们又接一路采集网关做第二个主站总线上的报文量几乎翻倍老仪表响应慢的话很容易冲突。稳妥做法是把设备按原有主站是否活跃分两类原系统不跑的设备比如压力表和温控仪表我们直接做主站轮询原系统在跑的PLC如果有多余空闲串口就接空闲口如果只有一个口就用RS485监听模式配合网关的以太网旁路或者干脆协商停机几秒把PLC程序拷出来分析通信报文。这个项目里老PLC都有空闲口所以问题不大但我在另一个项目里就碰到过只有一个口的设备后面踩坑部分细讲。2.2 网关选型的硬指标串口数、协议栈、算力硬件最终选了基于瑞芯微RK3568的工业网关四核A552GB内存4路RS485双千兆网口9~36V宽压输入无风扇设计。选它的原因串口数量够4路RS485完全覆盖了现场18个Modbus从站分成3条总线避免单总线负载过高。算力足够跑Python/C混合的采集服务RK3568虽然不强但处理十几台设备的轮询和压缩绰绰有余。双网口可以做物理隔离一个网口接OPC-UA设备网段另一个网口接上行的车间局域网避免跨网段路由问题。带硬件看门狗和掉电检测这是工业网关的基本素养。这里我要强调一下算力评估。边缘采集网关的算力需求经常被高估或低估高估的人用x86工控机贵而且功耗大低估的人用ESP32结果轮询一多就卡死。像这种几十个点位、秒级采样、压缩和HTTP上传的任务四核A55级别刚好够还能剩余不少CPU做本地清洗和日志。2.3 电源与隔离工业现场最容易翻车的点现场实施时翻过最大的车不是协议而是电源。第一批串口设备接好后Modbus轮询一直超时。排查半天发现网关的RS485地和其中一台变频器的地存在电位差导致总线电平异常。后来在每路RS485上加了带隔离的收发器模块网关外壳做了单点接地问题才消失。所以硬件层面我给所有串口设备加了光电隔离上行网络口全部用工业级交换机网关本身配了UPS电源。别小看这些细节车间里变频器一启动电网谐波和地环流能把你的通信打成一坨乱码。隔离型RS485收发模块单价也就几十块但能省下好几个晚上的排查时间。3. 协议适配层Modbus轮询调度与OPC-UA节点映射3.1 Modbus轮询不是while(1)定时调度与超时退避许多人在网上搜Modbus轮询写出来的都是while (1) { send_request(addr, reg); recv_response(); }但实际工程里绝不能这样写。原因有三一是不同从站响应时间差异大一个慢设备会拖累整条总线二是总线上可能还有原有主站采集端不能一直占着总线三是通信错误后必须退避否则会把总线打爆。我的做法是给每个从站分配独立的轮询定时器控制周期按设备重要性设置。温控仪表和压力表5秒轮询一次PLC的关键寄存器1秒轮询一次变频器因为现场走的是独立RS485可以1秒一次。这样设计之后整条总线的报文压力不大也不会干扰原有系统。轮询调度的核心伪代码大概是这样的# 每个设备一个独立task用等待队列结合deadline调度 async def poll_device(session, device, callback): while True: due time.monotonic() device.interval try: values await session.read_holding_registers( slavedevice.addr, addressdevice.start_reg, countdevice.reg_count, timeoutdevice.timeout ) callback(device, values, time.time()) except ModbusTimeoutError: # 连续超时3次后轮询间隔翻倍最多退避到60s device.interval min(device.interval * 2, 60) except ModbusCRCError: # CRC错误不清缓存但要记日志 logger.error(fCRC error on slave {device.addr}) await sleep_until(due)这里用到了异步协程而不是多线程。多线程在Modbus上特别容易踩坑两个线程同时对串口读写要么加锁加出一堆超时要么锁没加对直接乱帧。异步单线程模型天然避免了这个麻烦。3.2 OPC-UA客户端订阅的坑会话保持与发布间隔OPC-UA这边相对省心但也不是连上就完了。新设备控制器支持OPC-UA我用了开源的opcua-asyncio库做客户端。有几个坑值得提前说会话超时OPC-UA服务器默认的会话超时时间一般是几十秒到几分钟不等。如果网关侧长时间没有请求服务器会主动断开会话。必须启用心跳或者周期性调用read_value保活。订阅(Subscription)配置OPC-UA的订阅机制挺好用服务器按PublishingInterval推送数据。但注意PublishingInterval不是越短越好比如设备控制器内部是500ms刷新一次你设成100ms也只是重复推送旧值还增加负载。我统一设成1秒。节点ID解析OPC-UA服务器导出的节点ID有时候带命名空间索引类似ns2;i1001调试时用UaExpert这种工具看节点树很方便但程序里要处理好命名空间索引和节点标识符的转换否则连接时找不到节点。证书安全OPC-UA支持证书安全策略但老旧设备控制器往往只开Basic256Sha256或者None。为了兼容我把网关的安全策略设为None但这会带来安全隐患。如果网络环境允许建议在防火墙层面将OPC-UA网段和办公网隔离。订阅部分的核心逻辑是创建订阅、添加监控项、设置回调函数服务器每次发布推送后我们直接拿到最新的值。3.3 数据模型统一把寄存器和节点变成统一的点位表Modbus的寄存器地址和OPC-UA的节点ID形态完全不同但到了上层所有采集数据都必须变成一个统一的格式否则每个设备单独写一套后面做压缩和上传就是灾难。我设计了一个CSV格式的点位表每行定义一个点位device_id, point_name, source_type, source_key, data_type, scale, unit, sample_interval PLC_01, line_speed, modbus, 1;3;40001, float32, 0.1, m/min, 1000 CNC_02, spindle_load, opcua, ns3;i10012, float64, 1, %, 1000 TEMP_03, temp_value, modbus, 2;4;30001, int16, 0.1, degC, 5000source_type区分Modbus和OPC-UA。source_key对Modbus是从站地址;功能码;起始地址对OPC-UA是节点标识。scale用于原始值到工程单位值的换算很多PLC里存的是放大10倍的整数。sample_interval用于控制采样频率重要点位1秒一次慢变量可以5秒甚至更长。网关启动时加载点位表每个点位被注册成独立的采集任务数据进入统一的消息队列后续所有处理逻辑只认这个统一的数据结构。这样做的好处是新增设备只需要在表里加几行不用改代码。4. 时序数据差分压缩边缘侧先把90%的冗余干掉4.1 为什么压缩必须做在边缘数据量看着不大但算总账就会吓一跳。18个设备平均每个设备8个点位总共144个点位1秒一次采样一天就是144 * 86400 1244万条记录。如果按照浮点数和Unix时间戳各8字节计算一天原始数据约200MB一个月就是6GB。这还没算Modbus轮询里的重复扫描冗余。直接把这200MB推到MES后端不仅占用车间到机房的专线带宽存储和数据库压力也很大。更关键的是大量数据点其实是没有变化的重复值。工业设备在稳定运行阶段温控仪表的数可能半小时都不跳一次压力表稳定后也就小数点后几位在动。把这些重复数据原样传上去没有任何价值。所以压缩必须发生在边缘侧在数据离开网关之前就把冗余干掉。这里我用的是结合变化死区、线性拟合和Gorilla风格的差分压缩方案。4.2 差分压缩的三种策略我在实际项目中整合了三种互补方式变化死区(Deadband)数值变化不超过某个绝对值或相对百分比时不记录该点位的新值。比如温控仪表死区设为0.2℃压力表死区设为0.5%FS。这种策略把稳定期的数据量直接减掉一个数量级。斜率限幅/线性拟合对变化趋势稳定的连续变量如液位匀速上升用起点时间戳起点值斜率代替中间所有采样点。实时性要求不太高的场景甚至只需要在值偏离拟合直线超过阈值时才推送一次。Delta-of-Delta时间戳压缩对真正需要记录的每个值不再保存完整时间戳而保存时间戳的差分值的差分值Gorilla算法核心思想。因为工业采样周期固定时间戳的delta稳定delta-of-delta大概率是0几个字节就够存一个时间戳差异。4.3 一个可落地的差分压缩实现示例下面给出一个简化但真实的差分编码器实现用来压缩一串带时间戳的浮点值。生产环境中我封装成了C的共享库给Python侧用ctypes调用import struct def encode_varint(value): ZigZagVarint编码有符号整数 zigzag (value 1) ^ (value 63) buf bytearray() while zigzag ~0x7F: buf.append((zigzag 0x7F) | 0x80) zigzag 7 buf.append(zigzag) return bytes(buf) def encode_gorilla(records, prev_ts0, prev_delta0): records: [(timestamp_ms, value_float)] 返回: 压缩后的字节流 out bytearray() first_ts, first_val records[0] out struct.pack(Qd, first_ts, first_val) # 首点完整保存 prev_t, prev_delta first_ts, 0 for ts, val in records[1:]: delta ts - prev_t d_delta delta - prev_delta out encode_varint(d_delta) out encode_varint(struct.unpack(q, struct.pack(d, val))[0]) prev_t, prev_delta ts, delta return bytes(out) def decode_gorilla(data, point_count): 反向解码用于网关本地缓存里的合并读取 # 此处省略完整解析过程核心是读首点、再逐个还原d_delta和value pass对浮点数的处理我用了一个取巧但是足够用的方式把float64的bit pattern解释成int64再做ZigZagVarint编码。因为工业数据的小数变化大多发生在低位高位字节常常一样这样压缩效率接近整数。实测同一段1万条温控数据原始约160KB时间戳双精度浮点差分压缩后只有约8KB压缩比超过20:1。4.4 重组与校验接收端怎么还原压缩后的数据通过MQTT以JSON或者二进制块的方式上传。我选择了MQTT的二进制payload然后用msgpack封装这样既保留结构化字段又比纯JSON省流量。每个payload包含设备ID、点位ID或点位组ID本次数据的起始时间、采样间隔压缩算法标识校验和CRC32差分编码后的二进制块接收端收到后按照算法标识选择对应的解码器解出原始时间戳和值序列再写入时序数据库。这里有个关键点接收端的时钟和网关的时钟必须做同步。后面断网自愈章节里会详细说明如果时间不同步补传的数据会错位。我在接收端用独立的校验和检查解出来的点数、时间戳是否连续、数值是否在合理范围内三重视角做校验。现场还真抓到过几次因为车间震动导致SD卡偶发位翻转造成的数据损坏如果没有校验这些坏数据就会直接进入生产报表。5. 断网自愈缓存、重连与数据补传5.1 断网检测TCP心跳与串口超时分开处理车间的网络条件没有机房那么可靠交换机老化、网线松脱、光纤被叉车撞断我都遇到过。断网自愈的前提是能够快速准确地检测到断网。上行链路我用MQTT的keepalive机制做心跳保活间隔设成10秒。如果超过两个保活周期没收到服务端响应判定上行网络断开。注意不能只看TCP连接是否还在因为TCP连接在弱网环境下可能还维持着但实际上数据已经发不出去。MQTT这种应用层的心跳比TCP的socket检测更可靠。串口侧的Modbus轮询超时不能算作断网只能算作设备侧通信异常。这里要把两个概念分开上行断网影响数据上报下行故障影响数据采集。自愈机制主要是针对上行断网。5.2 本地环形缓存写满怎么办检测到断网后采集依然继续数据压缩后写入本地缓存。缓存设计上我没有用SQLite因为高频写入和并发访问会让SQLite成为瓶颈。我选择了LevelDB风格的本地KV存储key是设备ID时间戳value是压缩后的数据块。缓存不能无限膨胀否则断网一个月存储也会爆。我设计的是环形缓存按容量水位分三档低于50%容量正常写入不删除任何数据。50%~85%开始对超过保留期的数据进行数据降采样比如原始5秒精度改为60秒精度把老数据粗化后继续保留。超过85%优先删除最老的、低频点位的原始数据保留关键点位数据同时发告警告知运维人员网关缓存即将写满。实际测试中144个点位、1秒精度、压缩后每天约15MB网关配了64GB的工业SD卡按这个速率可以缓存超过2年。所以环形缓存的主要作用不是防爆盘而是防异常情况比如车间网络整整一周没恢复。5.3 重连后的数据续传时间戳排序与去重网络恢复后自愈机制要面对几个头疼的问题重复数据、乱序数据、断网期间时间戳并没有对齐。我的续传策略是按时间分批补传配合接收端去重网关维护一个last_acked_timestamp每成功上传一批数据并收到服务端的ack后更新这个值。断网恢复后先从最早的未确认缓存块开始每1秒发一批限制上行带宽占用。每批数据块都带独立的batch_id接收端维护一个已处理batch_id的布隆过滤器重复的批次直接丢弃。接收端在写入时序数据库前按时间戳做排序时间戳完全相同的记录以先到达的为准。这个方案跑了一年多断网发生过七八次最长一次断了3天恢复后补传数据全部正确入库没有一条丢失或重复。这里的技术关键是batch_id去重和接收端的幂等写入缺一不可。5.4 自愈的边界什么情况真救不回来自愈机制不是万能的有几种情况是救不回来的设计时要提前想好网关断电超过缓存保留期数据直接丢失只能靠告警提醒运维人工处理。设备侧通信故障超过缓存保留期同理这段时间的数据无论如何都拿不到了。缓存写满后被强制降采样原始精度丢失虽然还有粗粒度数据但精细分析就没法做了。所以自愈机制的真正价值不是保证永不丢失而是在网络抖动、短暂断网这种常见场景下可以无感恢复。极端情况必须通过告警让人知道这里有数据缺口而不是把缺口静默掩盖掉。我在网关状态页面专门展示每个点位的最后采集时间、最后上传时间、未上传数据量这样运维在第一时间就能看到缺口在哪。6. 现场实施踩坑记录那些不能写在方案书里的事6.1 Modbus从站地址冲突与CRC校验两个基础但致命的问题刚开始部署时我们把温控仪表和压力表分到两条总线用了不同从站地址以为万事大吉。结果一跑温控仪表的读数偶尔跳到压力表的数据段。排查后发现是接线问题两条RS485总线在端子排上被并到了一起导致网关发往总线的请求同时被两组设备收到应答帧在物理层就互相干扰了。那个端子排是之前施工队留的上面标识已经模糊我们接的时候没仔细核对。从那以后我养成了一个习惯动任何一个接线端子前先拿万用表测通断并拍照留档。CRC校验我说明一下Modbus RTU的帧尾有两个字节的CRC16校验很多串口库用打开就能用但有些老设备的CRC实现是不标准的尤其是国产仪表常见的Modbus变体地址域和数据域的处理跟标准不完全一致。遇到这种情况不要急着怪设备先用Modbus Poll或QModMaster这类工具抓一下原始报文对照标准CRC算法手算一遍就能定位是设备发错还是库解错。我用Python自带跑了一遍标准CRC发现某个国产仪表发的CRC确实算错了最后在采集代码里加了一个宽松CRC检查开关只在特定从站地址上启用。6.2 Modbus轮询频率会覆盖其他数据一个真实的PLC冲突这是网上很多人搜的问题我也在项目里遇到过症状很诡异用西门子S7-1200做Modbus TCP主站轮询读取变频器频率的时候PLC里原本通过Modbus读取的其他数据块会被覆盖掉。根因在于S7-1200的Modbus指令是通过背景数据块保存通信参数的如果你在OB1里写了多个Modbus_Master调用但它们的Instance DB没分开或者同一时刻对同一个通信连接发起了多个请求后面的请求会把前面请求的返回区覆盖。这个坑提醒了我一件事用网关同时采集设备数据时如果原有主站PLC也在轮询同一批寄存器采集轮询的时间和它重合虽然物理层不会冲突但应用层上如果PLC的轮询请求写到了相同的数据块就会出现我读到的数据突然变成对方的请求地址区的内容。解决办法有两个采集网关的轮询周期不取固定值而是加随机抖动尽量避免和PLC的轮询严格同频。在PLC侧如果程序可改当然非侵入原则下不能改那就把多个Modbus调用分配到不同的连接或者不同的Instance DB。对于非侵入改造我只能选择第一种方案。实测把温控仪表的轮询周期从固定5秒改成5秒±1秒随机抖动后数据覆盖问题没有再出现。6.3 信捷PLC作为Modbus TCP服务器与OPC-UA转换器的兼容性热词里有配置信捷PLC作为Modbus TCP服务器与海康相机通讯这个我虽然没直接做过相机但遇到过信捷PLC做Modbus TCP服务器然后被我们网关读取的情况同样踩了坑。信捷PLC的Modbus TCP实现有一些细节和标准Modbus TCP不太一样。比如它默认的轮询周期不能太短太短了PLC响应不过来会直接无响应另外它支持的寄存器区地址映射需要去手册里查表和通用的地址表对不上。当时网关读信捷PLC的D寄存器我用的是功能码03读保持寄存器地址从0开始读出来的数据却全都不对。后来用Modbus Slave模拟器验证了网关侧的请求帧没问题再用Modbus Poll去读信捷PLC才发现它的D区映射到了一个偏移地址上必须把地址加上一个固定偏移量才能读到。这类问题没有捷径只能看手册、抓包、翻文档一条条试。我建议做多厂商接入时手里始终备着一个Modbus Poll/Modbus Slave的授权版或者用开源的QModMaster配合以太网抓包工具Wireshark所有的协议兼容性问题都能快速定位。6.4 时间同步没有NTP的车间怎么对齐时间戳断网补传和高精度差分压缩都依赖一个前提网关上所有数据的时间戳是一致的。但车间环境经常没有NTP服务器网关和MES服务器的时间可能差出几分钟。如果时间不同步补传的数据就算一条不丢时序分析也会乱套。我在网关启动时用GPS/北斗模块授时或者在上行网络可用时用NTP同步。上行网络断开的情况下网关记录本地漂移等网络恢复后再校正并在校正后给所有缓存的未上传数据的时间戳做一个线性补偿。具体来说网关本地维护一个clock_offset_ms参数服务端返回当前UTC时间网络断开后就用本地单调时钟time.monotonic()推算绝对时间恢复后再修正。这个机制保证断网期间产生的数据时间戳是单调递增的不会因为系统时钟跳变导致数据乱序。写在最后的几点体会这个项目从进场到稳定运行花了三周真正改代码的时间其实不到一周大部分时间都花在现场排查通信干扰、协议兼容和设备不过电之类的问题上。我最大的体会是工业数采项目的难点从来不是某一项技术有多高深而是把这些技术组合在一起时能不能应对现场的脏乱差。差分压缩和断网自愈的代码再漂亮也比不上一个可靠隔离的RS485电路和一根标注清楚的网线来得重要。如果你正准备做类似的项目我的建议是先花两天时间把所有设备的通信协议摸清楚写一个设备清单和点位表再动手选型和编码在现场实施阶段务必做好接地、隔离、网线标签和时间同步最后再考虑压缩和自愈这些锦上添花的能力。顺序反了后面全是补窟窿的活。