2021年我接手了一个老车间的数采项目那是第一次真正意识到“工业数据”这几个字的重量。车间里有一台2006年出厂的注塑机、两条2009年的装配线主控是西门子S7-200和台达DVP系列通讯口只有RS485串口没有以太网模块更谈不上OPC-UA。生产经理想要设备OEE、报警记录和能耗曲线但设备本身就像个哑巴——数据明明在PLC内存里跑着却没有任何办法把它拿出来。刚开始我觉得这事简单不就是用Modbus协议去读寄存器吗真做起来才发现从“能读到数据”到“稳定、可靠、不丢数地拿到数据”中间隔着一整套工程问题轮询周期怎么定、数据怎么压缩、断网怎么办、重启之后怎么补。这篇文章就把这套“工业遗留设备非侵入式数采架构”完整讲一遍重点落在三个技术点上Modbus/OPC-UA边缘适配网关、时序数据差分压缩、断网自愈。如果你正在做工厂数据采集、MES对接、设备上云这类项目这篇应该能帮你少踩不少坑。1. 车间里的三代设备混战这个项目要解决的真实痛点1.1 非侵入式的定义不改逻辑、不改硬件、不承担停机风险“非侵入式”这四个字先要掰开揉碎讲清楚。它不是技术选型的偏好而是业务层面的硬约束。改造一个用了十几年的老设备工厂最怕两件事一是改PLC程序改挂了生产线停摆停产一小时可能就亏掉几个网关的钱二是改造验收时能跑后续维护升级要加点位又得动原厂逻辑厂商配合度低、周期长。所以项目启动会上跟车间定了三条红线不修改任何PLC原有程序、不更改设备硬件接线、不停机实施。这意味着数采网关只能“寄生”在设备已有的通讯端口上。具体到本项目大部分设备走的是RS485串口通过Modbus RTU协议从PLC的从站寄存器里读数据少量新一点的设备有以太网口走Modbus TCP。整个过程不需要在PLC上增加硬件模块也不需要改电气柜里的走线。这里有一个非常关键的前提要查清楚设备里的PLC从站功能是不是已经激活了。很多老设备默认用的是编程口协议比如西门子S7-200的PPI协议它本身不是Modbus。如果PLC程序里没有初始化Modbus从站指令块你光把通讯线接上发Modbus请求过去设备是不会理你的。我们这个项目里有三台设备最后是请厂商过来在程序里加了一段Modbus初始化指令MBUS_INIT相当于在一大段逻辑里塞了一个子程序调用主体逻辑完全没动这算最小程度的侵入大多数用户能够接受。但这个动作必须在停产窗口期做而且要提前跟设备厂商确认寄存器地址表和从站站号分配不然现场就是一团乱麻。1.2 数据捞出来只是开始采集链路不等于数据链路把Modbus寄存器读出来之后很多人觉得任务就完成了。其实不是这样。裸寄存器读出来的是“一个地址、一堆十六进制数”要变成MES能用的“设备状态、产量、良品率、瞬时能耗”中间还有一串活数据清洗、单位换算、位拼接比如两个寄存器拼一个32位浮点数、协议转换、本地缓存、断点续传、压缩上传。这些工作在边缘端做完比在云端做要合理得多。第一现场数据量大采样周期到秒级的话一台设备一天就是86400条记录几十台设备全量往云端推带宽和云端存储都吃不消第二现场网络没有办公室网络那么可靠一旦断网边端必须有本事把数据先存下来第三很多老设备通信能力弱只支持串口轮询你不可能让云端直接去轮询一个RS485总线上的从站。所以这套架构的核心思路是边缘网关做“翻译官仓库管理员”云平台只负责“看报表和发指令”。翻译官解决的是协议不通的问题把Modbus的裸寄存器翻译成OPC-UA信息模型和MQTT消息仓库管理员解决的是数据可靠性的问题先把数据稳稳当当落在本地再想办法传到云端。后面每一章讲的具体环节本质上都是这两个角色里的一部分。2. 边缘网关的硬件选型与软件架构为什么必须在现场放一台“翻译官”2.1 为什么不用DTU直接透传协议、缓存、安全三道坎做项目的时候有人问我现在市面上的DTU数据传输单元那么便宜把RS485转成4G/以太网透传不就行了何必放一台边缘网关这个问题问得很好我用实际项目里的三笔账回答。第一笔是协议账。DTU做的是物理层的透传它不管上层跑什么协议。如果云平台要读到Modbus数据云平台还得自己实现一个Modbus主站去轮询而Modbus轮询是有时序要求的RS485总线上同一时刻只允许一个主站发送请求延时、超时、重试这些逻辑放在公网链路上做基本不靠谱。DTU解决不了“设备说Modbus、平台说OPC-UA/MQTT”这种协议转换问题。第二笔是缓存账。DTU断网之后就是傻等数据在设备端没有被采集出来等网络恢复再去读已经来不及了——PLC的寄存器是瞬态值过了这个时间点你就永远拿不到那条数据了。而边缘网关在本地把数据落盘断网几个小时、几天数据都在本地仓库里躺着网络恢复后可以按时间顺序补传。第三笔是安全账。如果设备直接暴露在公网IP上那等于把PLC的通讯端口开到了互联网上一旦出安全问题后果不敢想。边缘网关作为唯一的数据出口对外只主动连接平台不对公网开放任何入站端口这是最朴素的边界防护逻辑。2.2 软件技术栈的选择验证过的稳定组合硬件方面我选的是无风扇工业嵌入式工控机CPU不用高Atom级别或者赛扬J系列就够关键是必须有原生或者硬件隔离的RS485串口、双网口、宽温固态盘电源支持9到36V宽压输入直接接到设备控制柜的DC24V回路上。网上那些几十块的USB转RS485模块短时间调试可以长期放现场大概率会出现丢帧、驱动不稳定、串口丢失的麻烦不建议用。软件栈我用的是Python 3.8 pymodbus串口/网口Modbus主站 asyncuaOPC-UA服务端 SQLite本地缓存 自研MQTT上传模块。有人会觉得Python干工业采集不靠谱但实际上对这个场景是完全够用的——Modbus轮询是毫秒级的慢速IO几百个点位每秒也就几百次操作Python并发模型里的asyncio足够应付真正要关注的瓶颈在磁盘IO和网络。Python的好处是开发快、协议库完整、后面要接什么数据服务都方便。网关内部按数据流向分了五层设备接入层各种串口/网口的Modbus信道、协议解析层寄存器映射、字节序转换、单位换算、本地存储层SQLite缓存队列、服务开放层OPC-UA Server、MQTT Client、本地Web调试页面、管理维护层时钟同步、日志、看门狗。每一层之间用简单的队列解耦Modbus采集线程只管把数据写进本地数据库上传线程只管从数据库拿数据推给平台两个线程互不阻塞这也是断网自愈能成立的基础。3. Modbus轮询详解寄存器勘察、扫描周期计算与读写冲突规避3.1 用Modbus Poll做寄存器勘察先画出地图再上路上现场前最重要的一件事是把每台设备的Modbus点位表摸清楚。我一般用Modbus Poll这个工具它就是个Modbus主站模拟器接上RS485转USB线就能跟PLC说话。勘察的时候要做三件事确认通讯参数波特率、数据位、停止位、校验位、确认从站站号、确认每个点位对应的功能码和寄存器地址。这里最容易出问题的是寄存器地址的“基址偏移”。Modbus协议层的地址是0开始的Protocol Address很多PLC厂商的文档里写的是1开始的Logical Address中间差1。比如台达DVP的D寄存器文档里说“D100”你发Modbus请求时的实际地址可能是99或者100这个必须拿Modbus Poll亲手测看哪个地址能读到预期值再在点表里记录。勘察完要产出一张点表这是整个项目的“地图”。字段包括设备ID、从站站号、寄存器地址协议层地址、功能码03读保持寄存器、04读输入寄存器、数据类型INT16、UINT16、INT32、FLOAT、字节序、量程、单位、缩放系数、轮询分组、描述。这张表后面要用来生成边缘网关的配置文件也是OPC-UA信息模型和差分压缩模块的数据字典。顺序别搞反我就是因为前期点位表录入时漏了一项字节序导致一条温度数据整整错了两天。3.2 扫描周期怎么算RS485总线是典型的时序预算问题Modbus RTU在RS485上是半双工轮询同一时刻只能有一个主站说话所以扫描周期是个实打实的时序预算问题不算清楚要么总线冲突要么数据刷新太慢。先给个计算模型。以9600波特率为例传输一个字节大约需要1.04ms包含起始位、数据位、停止位。你发一条“读10个保持寄存器”的请求报文是8个字节从站号1 功能码1 起始地址2 寄存器数量2 CRC校验2。如果读取的10个寄存器里放的是5个FLOAT每个占2个寄存器响应报文是25个字节从站号1 功能码1 字节数1 数据20 CRC2。再加上Modbus协议要求的3.5个字符时间间隔约3.6ms请求前、响应前、响应后各一次单笔事务的总耗时大约是41ms。假如一台设备有50个FLOAT点位一条报文最多读125个寄存器所以可以在一条事务里把这50个FLOAT100个寄存器全部读完实际上一笔事务就够了周期大约41ms。但如果点位分布零散比如每隔几十个寄存器才有一个有用的点你就得发好几条事务。比如分成5笔事务那周期就变成5×41ms约等于205ms。串口波特率再低一点比如4800时间直接翻倍。所以设计的思路是点表规划时尽量把同一设备的连续寄存器放在一个轮询组里一条事务能读完的绝不分两笔。8台设备挂在同一条RS485总线上每台周期200ms合计轮询一遍就是1.6秒左右。对大多数设备状态监控、产量统计场景1到2秒的刷新率完全够用。如果你要1秒以内的实时性要么提高波特率到38400甚至115200要么把设备拆到多条总线上。3.3 读写冲突和HMI共存别让你的网关变成搅局者Modbus不光是读设备常有需要写的场景比如设定温度、切换配方。这里有个大坑如果边缘网关周期性地去写一个保持寄存器而设备HMI或PLC内部逻辑也在写同一个寄存器就会产生互相覆盖的问题。我的处理原则是网关只读不写除非收到上位平台下发的明确指令写操作只做“命令触发”不做“周期刷新”。读取和写入共用同一条总线的代价是写入时总线会被占用读周期会有抖动所以写操作要加互斥锁并且尽量放在采样间隙。另一个容易被忽略的问题是HMI共存。老设备的RS485总线上通常已经挂着一个HMI触摸屏HMI本身就是一个Modbus主站。你再把网关并上去就变成了双主站两条轮询请求在总线上打架现场表现为数据偶尔跳变、HMI画面刷新变慢。解决思路有三种把HMI换到PLC的另一个通讯口上把网关节点设置为只在HMI轮询周期的间隙发送请求需要摸清HMI的轮询规律或者如果PLC支持把网关接到单独的主站端口。我们项目里最省事的做法是给PLC加了一个通讯扩展板HMI和网关各走各的口总线冲突的问题直接从物理上消除。4. OPC-UA地址空间建模把Modbus裸寄存器变成标准信息模型4.1 为什么网关要“说”OPC-UA而不是直接交裸数据前面数据采集用的是Modbus但整个系统的对外接口我选了OPC-UA而不是单纯让云平台来读Modbus或收原始报文。原因不只是“OPC-UA更现代”这种口号而是三个实打实的工程理由。第一上层系统集成成本低。MES、SCADA、能源管理平台这些系统基本都内置OPC-UA客户端接到一个标准OPC-UA服务端上配置一下连接字符串和节点路径就能读到数据。如果上层系统要去读Modbus它就得自己实现Modbus主站还得知道每台设备每个寄存器地址的映射关系集成成本高得多。第二信息模型自带语义。Modbus寄存器就是一个编号一个数它不告诉你这是温度还是压力单位是什么。OPC-UA的地址空间可以定义成“设备对象下面挂着变量节点”每个变量节点带描述、工程单位、数据类型等属性。上层系统拿到节点就知道这个值的含义不用在平台侧再维护一张映射表。第三网络安全模型成熟。OPC-UA支持TLS加密和证书认证允许你只授予MES系统某些设备的读取权限。这在制造业客户那里比较好交代审计的时候也能说清楚数据通道是受控的。4.2 信息模型设计设备、点位、属性三层结构OPC-UA的地址空间建模我这套分成三层。第一层是设备对象节点Object Node。比如ObjectFolder/Devices/InjectionMolding_01对应物理世界里那台注塑机。设备节点的属性包含设备编号、型号、厂商、上线时间、当前通信状态。第二层是点位变量节点Variable Node。挂在设备节点下面比如InjectionMolding_01/Temperature_Barrel1。每个变量节点设置DataType为Double或Int16设置EngineeringUnit属性为摄氏度或百分比加上Description描述“1区料筒温度”。变量节点的BrowseName和NodeId要稳定因为上层系统配置好之后如果你的节点路径变了对接就要重新来过。第三层是服务与诊断节点。这个是我自创的在每个设备下挂一个Diagnostics文件夹放几个只读变量LastPollTime最近一次轮询时间、CommStatus通信状态、TotalCommunicateErrors累计通信错误次数。这些诊断数据平时没人看一旦出问题排查起来是救命稻草。具体实现上用Python的asyncua库启动一个Server注册一个自定义namespace然后遍历点表配置用代码批量生成这些节点。几百个点位用循环建节点就好不要手写维护NodeId容易乱。这里要提醒一句OPC-UA Server加载完节点之后最好做一次地址空间的快照导出留作版本比对防止网关程序升级时节点结构漂移。4.3 部署验证UA Expert连上去看真实数据模型建好之后验证工具我推荐官方免费的UA Expert。它就是个OPC-UA客户端填上网关的IP和端口就能浏览地址空间。验证时主要看三件事节点树结构是否符合设计、每个变量能否订阅到实时值、数据类型和工程单位是否显示正确。这里有个实战细节UA Expert订阅的点位多了之后网关CPU占用会明显上升因为每个订阅都要进行值变更检测和推送。解决方法是把订阅的采样间隔调大默认100ms改成1000ms对绝大多数工艺监控足够了。另外OPC-UA协议本身也有心跳机制客户端和服务端之间的会话要保持连接如果网络抖动客户端会报“BadSessionIdInvalid”之类的错误这种时候要找网络原因不要急着怀疑网关程序。5. 时序数据差分压缩从“存全量”到“存变化”的工程实现5.1 工业时序数据的统计特征为什么值得做差分做压缩之前我先分析了一下这些数据的特征。工业现场采上来的数据跟互联网日志、金融行情有本质区别。设备温度、压力、速度这些量在稳态生产阶段变化非常缓慢相邻两个采样点的差值往往很小。比如注塑机料筒温度设定在220摄氏度实际温度在219.5到220.5之间波动一秒钟采一次相邻两次的差值常常只有0.1到0.3摄氏度。如果直接存绝对值的32位浮点每个点固定4字节一天就是345600字节几十台设备一年下来就是好几个GB存储和传输成本都很可观。但如果我存的是“差值”大部分差值用1到2个字节就能装下少数剧烈变化的时刻才需要多字节。这就是差分编码能省空间的基本盘。它不是要替代通用压缩算法而是先用领域知识把数据变成“更好压”的形态后面再叠加通用编码效果才明显。5.2 差分编码ZigzagVarint的完整编码流程具体编码流程我拆成五步每一步都有明确的理由。第一步是定点化。浮点数直接做差分会遇到精度问题所以先把原始浮点按物理量纲乘一个缩放系数转成整数。比如温度保留一位小数就乘以10转成整数2205然后做后续所有的差分运算。缩放系数放在点位表的元数据里解压时再除回去。第二步是分块。把同一个点位的连续256个采样点组成一个块块内才做差分。分块的好处是压缩和解压都局部化要查某段时间的数据只需要解压包含那个时间段的块不用把整年数据全解一遍。块的大小对压缩率和随机访问性能都有影响256是我试下来比较平衡的值。第三步是差分。块内第0个采样点存原始值的绝对整数后面的每个点都跟前一个点做差得到delta[i] value[i] - value[i-1]。这些delta有正有负直接用无符号Varint编码不了负数。第四步是Zigzag编码。它把有符号整数映射成无符号整数映射规则是n大于等于0时变成2nn小于0时变成2|n|-1。比如0变成0-1变成11变成2-2变成32变成4。这样处理后所有delta都变成了非负整数而且绝对值小的delta编码出来依然很小。第五步是Varint编码。Varint的原理是用每个字节的低7位存数据最高位表示后面还有没有续字节。0到127之间的数用一个字节就完事128到16383用两个字节以此类推。经过差分和Zigzag之后大部分delta都落在127以内所以大部分点只用一个字节。而原始存储一个浮点要4个字节这一下就省了75%。时间戳也有压缩空间。如果采样周期是固定的1秒那时间戳不需要逐点存储块首存一个起始Unix时间戳后面按周期推算就行。如果采样间隔不固定就对时间间隔做同样的差分Varint编码效果也不错。5.3 存储结构块索引与随机访问怎么配合压缩完的数据不能糊里糊涂塞进去得有一个可查询的存储结构。我在SQLite里建了两张表。第一张是数据块表ts_data_block字段包括块ID、设备ID、点位ID、起始时间、结束时间、采样点数、块编码数据BLOB、块内首值绝对值、缩放系数版本。查询某个时间段的数据时先用起始时间和结束时间在这个表上做索引查询拿到相关块的ID再按块解压。这张表是只追加的永远不修改、不删除单条记录只在滚动淘汰时按块ID整块删除。第二张是块索引表ts_block_meta记录每个块对应的时间范围和校验值用于快速定位和完整性校验。查询逻辑是先查块索引确定要解压哪些块再读块数据解压回原始时序值。实测下来查询一天的压缩数据解压耗时基本在几十毫秒级别完全可用。5.4 实测压缩率和CPU开销数据比感觉更诚实我拿一条实际温度曲线做了个测试。原始数据是每秒采样一次、32位浮点、一天86400个点原始大小约345.6KB。经过“定点化分块差分ZigzagVarint”这一套压缩后平均每个点1.2字节一天的数据大约103.7KB压缩率70%。再叠加LZ4快速压缩可以把每个点压到0.9字节附近压缩率接近78%。要注意的是LZ4解压会带来额外的CPU开销而且对随机访问不太友好所以我只在定期归档时叠加LZ4实时存储只做差分编码。CPU开销方面在Atom级别的工控机上一秒采样32个点位、每256点编码一个块编码耗时可以忽略不计峰值CPU占用增加不到3%。真正的开销在解压和网络上传但这两个操作都可以异步做不影响采集线程的实时性。这个数据说明对工业时序数据做领域定制的差分压缩性价比是很高的。6. 断网自愈本地缓存、补传机制与掉电保护6.1 工业网络的真实可靠性先做最坏打算做工业项目久了我对网络可靠性的信任度很低。现场环境里交换机重启、光纤被叉车碰断、配电房停电导致整个机柜掉电、施工误拔网线这些事我都遇到过。断网不是“可能不发生”的黑天鹅而是“什么时候发生”的灰犀牛。所以断网自愈不是加分项是必备项。设计目标定得很明确哪怕网络断开72小时网关也要继续按秒级周期采集所有点位数据并存到本地网络恢复后在不丢数据、不重复数据的前提下把离线期间的数据补传到平台。整个过程中采集线程和上传线程完全解耦。6.2 本地缓存实现SQLite WAL模式滚动淘汰本地缓存我没有用内存缓存加定时落盘的方案因为现场最怕的就是进程崩溃或掉电导致缓存丢失。直接的做法是每采到一个点值就写一条记录到SQLite数据库。SQLite在这种“单进程写、批量读”的场景下表现稳定关键是要开启WAL模式并设置synchronousNORMAL。WAL模式的好处是写操作不阻塞读操作而且崩溃恢复能力好。synchronousNORMAL的意思是事务提交时不需要等数据刷到物理磁盘才返回但WAL文件本身保证了崩溃时最多丢最近一小段数据不至于把整个数据库搞坏。对于秒级采样的数据丢掉最后几毫秒的数据完全可以接受而写入性能比全同步模式提升明显。为了避免本地磁盘被无限增长的数据撑爆缓存表做滚动淘汰保留最近7天的数据超过7天按块自动删除。这个天数要根据平台侧容忍度和磁盘容量来定64G固态盘存7天秒级数据绰绰有余。淘汰逻辑用定时任务在低峰期执行不要在采样循环里做删除操作。6.3 补传逻辑与幂等性别让数据重复捅出乱子网络恢复后的补传要比“把所有数据倒过去”复杂一些。我采用的策略是“实时优先、补传靠后”网络恢复的前5分钟只传实时数据保证平台看到的是“设备现在还活着”5分钟之后再启动补传任务按时间正序把本地缓存里未上传的数据批量推给平台。补传时的关键设计是幂等性。平台侧接收数据不能简单地“来一条存一条”因为补传和实时传输在时间上可能交错同一条数据可能因为网络超时被重传两次。解决办法是在每条数据上带上设备ID点位ID采样时间戳这个三元组平台侧在存储层对这个三元组做唯一索引重复插入直接忽略。这样不管补传任务重试多少次平台数据都不会出现重复记录。另一个细节是时间戳对齐。网关在断网期间如果本地时钟漂移补传的数据时间戳就可能是错的轻则曲线出现毛刺重则上报的数据被边缘计算任务当成异常值。所以网关必须能联网校时。我在网关里加了NTP客户端开机时校时之后每4小时校时一次如果NTP不可达就把本地时钟和一个“未校时标志”一起上报平台侧可以根据这个标志对数据做降级处理。6.4 重连策略指数退避抖动防止“羊群效应”网关断网重连要特别注意“羊群效应”——如果整条线路的十几个网关同时断网、同时恢复所有网关会同时发起连接平台端口一下就被打满了。所以重连不能做成“网络一恢复就立刻连”要采用带随机抖动的指数退避策略第一次重连等待1秒第二次2秒第三次4秒逐步增大到最大值60秒并且每次等待时间加上一个0到1000毫秒的随机抖动。这样即使几十个网关同时恢复它们的重连请求也会均匀散开平台侧的压力会小很多。重连的探活也不能只靠TCP连接状态因为TCP连接断没断有时候要很久才能感知到。我在MQTT层用keepalive心跳默认60秒超过两个心跳周期没收到的服务器响应就判定连接失效主动断开重建。同时监控上传队列长度如果队列持续增长说明网络可能已经出问题提前打日志而不是傻等连接超时。7. 上线半年踩过的坑字节序、时钟漂移、假断网与PLC干扰7.1 字节序与字序工业数据里最阴间的错位Modbus协议本身是大端传输但32位浮点或者32位整数由两个16位寄存器构成时不同厂商的排列方式完全不一样。常见的有ABCD大端、CDAB字交换、BADC字节交换、DCBA双端反转四种。症状表现为读出来的温度值是几百甚至几万或者两个数值在小数点位置乱跳。这个东西光看文档经常不准最稳的办法是造一个已知值比如把PLC里的某个D寄存器手动写入一个特定浮点数然后看网关读出来是什么字节序把那台设备的字节序参数定下来。7.2 时钟漂移时间戳穿越导致的数据错乱有段时间平台侧发现某台设备的能耗曲线每天都有个奇怪的尖峰查了半天发现是网关的实时时钟RTC电池没电了。设备断电重启之后系统时间变成了出厂默认的2015年等网络恢复校时又突然跳回当前时间中间这十几分钟“穿越”的数据全被存了下来补传上去之后平台侧就把这段时间算成了异常尖峰。后来我在网关程序里加了开机检测如果系统时间比编译版本时间还早说明RTC不可靠启动后阻塞数据上传直到NTP校时成功才放开。这个机制虽然简单但后面再没出现过“穿越数据”。7.3 假断网与PLC通信干扰网关把某台设备标记为离线但是现场看设备明明在正常运行。排查下来发现这台设备的PLC程序正在被工程师用编程软件下载程序下载期间PLC的Modbus从站通信是被暂停的连续好几次轮询超时网关就判定设备离线了。从那以后判定离线的策略从“单次超时”改成了“连续5次超时或者10秒内无有效响应”并且把通信错误单独记录成诊断数据不直接参与离线状态计算。这样既能容忍设备侧临时干扰又不会让故障被掩盖。还有一次比较隐蔽的问题是RS485总线上的接线问题。使用了劣质USB转485模块发送方向切换时RTS信号控制不干净总线上经常出现杂散字节导致CRC校验错误率高。排查时用Modbus Poll抓包对比才找到原因网关发的请求报文和Modbus Poll发的一模一样但网关这边收到的响应就是偶尔坏一帧。后来换成了带自动流向控制的工业级串口卡错误率直接归零。写在最后的实战心得这套架构从2021年底上线到现在稳定运行了两年多最深的体会是工业数采的项目难点从来不在某个单点技术上而在所有环节的咬合。Modbus轮询调得再快断网数据丢了等于白调差分压缩省下来的空间如果补传幂等性没做好平台侧数据乱成一团反而更麻烦。每当你觉得某个环节“差不多行了”的时候它八成会在你最不希望的时间出问题。如果再做一个类似项目我会在前期多花一倍时间在点位勘察和点表维护上字节序、缩放系数、功能码这些字段录入越规范后面的OPC-UA建模、压缩编码、断网补传就越顺畅。项目落地之后点表也要留版本管理设备改造过、PLC程序升过级点表必须跟着更新不然某个点位数据突然不对了你根本不知道是网关的问题还是现场那边变了。技术方案可以有多种选择但工程交付拼的是谁能把细节管住。这套架构里的每一个模块都不算高深合在一起就具备了处理真实工厂数据采集问题的能力这也是它到现在还在稳定跑着的原因。