PLC数据采集25种方法全解析：从Modbus到OPC UA与协议转换网关

大概七年前，我第一次去一个老车间做设备联网。车间里既有用了快二十年的旧PLC，也有刚上线的新设备，甲方只给了一句话：“把数据弄出来，放到大屏上。”当时我意识到，“PLC数据采集”这件事最难的不是软件怎么写，而是在五花八门的通信方式里找准那条路。这些年我陆续接触过的采集路径，掰着指头数一数，至少有25种——从最传统的串口轮询，到最近几年流行的云边协同，每一种都有它存在的理由和适用边界。

这篇文章就把这25种方法按“主路径”梳理一遍。每一种我都会讲清楚它是什么、适合做什么、实操时容易在哪个环节翻车。不管你是刚入行的自动化工程师，还是要给老工厂做数字化改造的集成商，这份清单都能帮你少走不少弯路。

1. 先别急着选方法：PLC数据采集的三个层次与分类思路

1.1 一条采集链路里藏着三个层次

很多人以为，PLC数据采集就是“上位机连上PLC读寄存器”。真到现场才发现，一条完整的数据链路要穿过三层：

第一层是物理链路。数据到底走什么介质，RS232串口线、RS485双绞线、工业以太网线、光纤，还是4G/5G无线电波。这一层决定了传输距离和抗干扰能力。

第二层是通信协议。物理链路铺好之后，双方得用同一种“语言”对话，Modbus RTU、Profinet、EtherNet/IP、OPC UA，这些协议决定了数据怎么组织、怎么校验、怎么握手。

第三层是数据表达。对PLC来说，数据可能放在保持寄存器里，可能在DB数据块里，也可能以标签、文件甚至Web页面的形式存在。采集程序最终要落到这一层才能把“0和1”变成有价值的产量、温度、状态。

这25种方法并不是25条完全不相干的路径，更多是这三层要素的不同组合。理解了这个框架，后面看任何方法都不会晕。

1.2 25种方法先看一张索引表

我在下表里把25种方法按五类主路径排开，编号从1到25。后面每一节会挑重点展开，但先建议你把这张表通读一遍，建立全局感。

1.3 选型前必须问自己的四个问题

方法再多，落到具体项目上能用的往往只有两三种。我的习惯是先问四个问题，答案基本决定了选型方向：

• 数据实时性要求是什么级别？毫秒级联动和分钟级报表，走的完全是两个技术路线。
• 现场网络条件如何？车间里有没有现成的工业以太网，网段怎么规划，能不能碰PLC所在的控制网。
• PLC的品牌和固件版本支持哪些协议？有些老型号只开放串口，有些新型号原生带OPC UA。
• 数据最终要去哪里？是本地SCADA、关系数据库、MES，还是云端平台，不同目标决定了数据出口需要什么格式。

把这四个问题写在纸上，25种方法里能用的基本划掉一大半。剩下再谈细节，效率会高很多。

2. 从串口到现场总线：五种传统但不会消失的采集方法

2.1 Modbus RTU：万金油不是吹出来的

RS485总线把几十台设备串在两根线上，主站挨个点名：“1号站，把你的寄存器1到10发给我。”这种主从轮询机制看起来古老，实战中却几乎没被淘汰。我做过的项目里，至少一半的最底层通信仍然是Modbus RTU，因为绝大多数PLC、仪表、变频器、电表都内置了这个协议，成本低、排查方便、上位机写几行代码就能读。

实操重点是参数对齐：波特率常见9600、19200、38400，校验位通常是8E1或8N1，从站地址不能冲突。真正坑人的是数据解释，比如一个32位浮点数，用两个16位寄存器存放，不同厂商对“高低字顺序”的处理不一样，读出来数值不对往往就是这里出了问题。还有地址偏移，有人跟你说是40001，有人说是0，其实是同一个寄存器，映射表一定要现场验证。轮询周期也要算：波特率9600时，56字节左右的请求帧加响应帧，一台设备大约耗时30毫秒，30台设备轮一圈将近1秒，只适合秒级采集。

2.2 Modbus ASCII：文本帧的“慢速”场景

Modbus除了RTU，还有ASCII模式。区别在于RTU用二进制帧加CRC校验，ASCII把每个字节拆成两个十六进制字符发送，用LRC校验。看起来笨重，但有一个好处：报文是纯文本，串口调试助手里一眼能看懂，出问题时定位特别快。

代价也很明显，同样的数据量，ASCII报文长度大约是RTU的两倍，通信效率基本减半。现在新项目很少主动选它，但在两种场景会碰到：一是某些老旧仪表只支持ASCII模式，二是现场数据量很小、对速度无所谓，维护人员又习惯拿着终端看原始报文。如果遇到不确定的旧设备，先别急着换线，拉出Modbus参数表看协议模式是RTU还是ASCII，支持程度会影响你选采集器还是换仪表。

2.3 Profibus DP：老工厂绕不开的DP总线

Profibus DP在欧洲产线里扎根很深，物理层是RS485，但通信机制和Modbus完全不同。它靠一个主站管理一串从站，主站可以配置成循环扫描，数据传输效率和实时性比Modbus好。现场常见的是9针D型接口，紫色电缆，拨码开关设站地址。

采集Profibus DP设备的数据，通常不是直接拿电脑接总线，而是用一个Profibus DP主站模块或者DP转以太网网关。实操中最容易踩的坑有三个：站地址重复导致总线反复重连；终端电阻没拨到位，链路时通时断；GSD文件版本太旧，导致组态时从站类型识别不出来。还有一点，DP总线的波特率由主站自动检测，如果某段线缆过长或者屏蔽层接地不好，整个段的波特率会一直波动，轮询周期忽长忽短。采集程序里不能假设固定周期，要用时间戳去计算真实间隔。

2.4 CANopen：设备级分布式控制

CANopen基于CAN总线，在设备级控制里非常常见，典型应用是伺服驱动器、变频器、阀岛和传感器网络。数据交换分两种：SDO用来做非周期性的参数读写，适合配置和诊断；PDO用来做周期性的过程数据交换，速度快，适合实时控制。

想采集CANopen设备的数据，常用两种路径。一是电脑插一块CAN卡，通过对象字典读取；二是用CANopen转Modbus TCP或转OPC UA的网关，把一根CAN总线上的设备映射成统一的寄存器地址。实操时注意：CAN总线的波特率必须全网络一致，常见125K、250K、500K；EDS文件要跟设备固件严格对应，否则对象字典里有些索引会读错。另外CANopen协议本身没有完全定义的节点必须用NMT命令先进入运行状态，很多采集程序漏了这一步，设备上电后一直收不到PDO数据。

2.5 DeviceNet：接线方便的设备总线

DeviceNet同样是CAN物理层，但比CANopen更“傻瓜化”，电缆里直接带了24V电源，传感器、阀岛、变频器挂上去就能供电和通信。它采用CIP协议的对象模型，显式报文用于设置参数，隐式报文用于周期传输I/O数据。在汽车生产线、包装设备里，DeviceNet曾经占有率很高，现在慢慢被EtherNet/IP替代。

采集DeviceNet设备，最常见的办法是用协议转换网关，网关一侧作为DeviceNet扫描器，另一侧输出Modbus TCP或EtherNet/IP，上位机只需读标准寄存器。这个过程中比较麻烦的是网络节点地址和波特率设置，DeviceNet节点地址用拨码或软件设，必须和网络组态一致。另外DeviceNet线缆供电电流有限，挂载设备太多时电压会掉，导致部分节点频繁离线。采集程序要做节点掉线重连的自动处理，不能一掉线就永远卡住。

3. 工业以太网时代：七种基于IP/实时总线的采集方法

3.1 Modbus TCP：以太网轮询的默认选择

Modbus TCP就是把Modbus的帧装进TCP/IP包里，默认端口502。它比RTU省去了CRC校验，因为TCP层已经保证可靠传输。几乎所有中高端PLC都支持Modbus TCP服务器或客户端，这让它成了工厂数据采集从串口转到以太网后的默认选择。

写采集程序时，我见过太多人反复新建Socket连接，读一次数据就断开一次。TCP建立和断开都是有开销的，快速轮询时这种写法会给PLC通信模块造成不必要的负担。正确做法是建立长连接，设置合理的超时和重试机制。另外一个常见误区是“一把梭”——把PLC里所有寄存器从头到尾读一遍，其实绝大多数项目只需要几十个变量，按需读取既能降低负载，也能减少对控制系统的干扰。还要注意，502端口在部分场景会被IT防火墙拦掉，跨网段采集前最好先确认网络策略。

3.2 Profinet IO：欧系PLC的原生以太网总线

Profinet是欧系PLC最主流的工业以太网总线，分RT和IRT两种实时等级。RT基于标准以太网，普通工业交换机就能跑；IRT要做时间同步，要求网络设备支持相应机制。采集Profinet设备的数据，一条路是PLC侧做数据交换，把要读的数据映射给第三方系统；另一条路是用Profinet网关，网关作为IO控制器去连接PLC或远程IO站，再把数据转成Modbus TCP或OPC UA。

实操中要注意GSDXML文件版本和设备具体硬件版本匹配，组态时站名、IP地址、设备名三者必须完全对应。Profinet对网络质量比较敏感，接入了普通办公交换机或者网络里有广播风暴，IO设备会周期性报故障。做采集系统时，我给Profinet网段单独划分VLAN，避免办公网干扰。如果你只是偶尔读几个变量，不要一上来就想霸占整个Profinet IO周期，占用槽位的做法影响面大，先考虑PLC是否提供开放接口。

3.3 EtherNet/IP：美系产线最常遇到的工业以太网

EtherNet/IP由CIP协议扩展而来，对象模型很严格，分隐式报文和显式报文两种。隐式报文是周期性IO数据，适合实时采集；显式报文是请求响应式，适合读参数、诊断信息。采集EtherNet/IP设备，常用“扫描器”软件或网关，比如用支持Scanner功能的网关去建立连接，设置RPI（请求包间隔）为10毫秒或100毫秒。

这个协议给我的感觉是兼容性好，但配置复杂。它的“连接”概念很强，采集端相当于要主动向PLC发起IO连接，连接的令牌（CIP Connection）数量有限，建太多连接可能触发PLC端资源溢出。另外RPI设得太短会明显增加PLC通信模块的CPU占用，建议先用100毫秒试，确认现场HMI和编程软件都没有异常后再缩短。采集程序里还要考虑连接超时和“闲置报文”机制，长时间不发控制包，连接会被对方自动断开。

3.4 EtherCAT：帧列车上车下车的实时采集

EtherCAT的通信原理很特别：主站发出一帧以太网报文，像一个高速列车经过每一站，从站设备在报文经过时“上车”带走自己的数据，再把属于自己的数据“放下”。因此它不需要每台设备单独收发，帧利用率极高，同步性能可以达到微秒甚至纳秒级，是伺服运动控制场景的主流选择。

直接做EtherCAT数据采集的门槛比前面几种都高，通常需要主站卡或支持EtherCAT主站的控制器，还要管理从站配置表。对大多数数据采集项目来说，性价比最高的方式是使用协议转换网关，网关作为EtherCAT主站或从站接入，把伺服状态、位置、电流映射成Modbus TCP寄存器。需要注意EtherCAT对网线和接插件质量要求高，劣质水晶头会导致断帧，错误计数器不停上涨，现场表现就是数据偶尔跳动。

3.5 POWERLINK：管理节点轮询的开源实时方案

POWERLINK是一个开源实时以太网协议，核心思路是一个管理节点（MN）按周期轮询所有从站（CN），轮询周期可以做到毫秒甚至亚毫秒级。它和EtherCAT思路不一样，更像一个“高速但有纪律的Modbus”，网络上所有设备都严格听管理节点调度。

在设备制造和运动控制场景里，POWERLINK还有一定保有量。采集方式和EtherCAT类似，普通电脑很难直接接入，通常通过网关做协议转换。实操时要重点确认管理节点的周期设置，如果周期是1毫秒，网关映射的数据更新时间也就是这个量级；如果周期被设备商改成了10毫秒，采集程序里设再短的读周期也拿不到更快的数据。开源协议的优势是没有授权费用，但生态相对分散，不同设备商的从站实现细节会有差异。

3.6 CC-Link IE：日系产线里的高速循环通信

CC-Link IE是日系PLC产线里的高速以太网总线，基线是千兆带宽，用循环通信加瞬时通信的方式交换数据。它的时间同步和实时性做得不错，在日系自动化产线覆盖率很高。国内很多消费电子、汽车零部件产线里，遇到这种协议的概率相当大。

采集CC-Link IE数据，最稳妥的路径是使用对应PLC厂商或第三方网关的协议转换方案，网关作为网络中一个站，把循环通信数据映射成Modbus TCP、OPC UA等通用协议再转发给上层。实操中常见问题是站号设置和网络拓扑规划不严谨，导致循环通信建立失败。还有一点，CC-Link IE的循环数据区是按字组织的，映射到Modbus寄存器时要清楚每个字对应的站号和地址偏移，否则数据会对错位。

3.7 实时总线的采集思路：网关与主站卡是常态

把3.4到3.6放在一起看，会发现实时总线有一个共同特点：它们为了追求实时性和同步精度，牺牲了“通用电脑即插即用”的能力。普通PC的网卡很多根本解不到EtherCAT帧里的点位数据，更不用说参与同步时钟。

所以这类场景的采集方案基本是两条路：一是专用主站卡加厂商SDK，开发门槛较高但性能最好；二是协议转换网关，把实时总线翻译成Modbus TCP或OPC UA，成本低、实施快，缺点是采样周期受网关转换能力限制。对绝大多数数据采集与可视化项目，我推荐后者，前提是先确认网关能覆盖你的从站数量和更新时间要求。

4. 软件层面做文章：七种上位机与平台侧采集方法

4.1 OPC DA：COM时代的Windows专属

OPC DA是OPC基金会在COM/DCOM时代推出的标准，核心解决“一个上位机同时对接多家PLC”的问题。只要每个PLC厂商提供OPC DA服务器，上位机就通过统一的OPC客户端接口读取数据。

听起来很美好，落地却很痛苦。OPC DA只能跑在Windows上，依赖COM/DCOM组件，跨机器访问时要在防火墙、权限、DCOM配置里折腾半天，经常出现“本机能读、别的电脑读不了”的情况。而且COM接口定义了32位和64位差异，采集服务一做成服务程序就各种权限问题。现在不建议新项目用OPC DA，但存量老SCADA系统里它还很常见，如果你要对接这些老平台，得接受它的脾气。

4.2 OPC UA：跨平台协议栈与证书管理

OPC UA是OPC DA的全面升级，不再依赖Windows，可以运行在Linux、边缘网关甚至PLC内部；不再依赖COM，改用自带的二进制协议栈，默认端口4840；还加入了加密、证书、信息模型等机制。

现代PLC不少已经内置OPC UA服务器，采集程序直接连PLC读命名空间里的节点即可，不再需要额外装驱动。它比OPC DA安全得多，但也带来了“证书管理”的新麻烦：客户端首次连接服务器时要校验服务器证书，双方证书链不信任时连接会被拒绝。很多项目卡在这一步，解决办法是提前把PLC侧证书导出来，安装到采集服务器的受信任根证书目录里。另外，OPC UA信息模型允许服务器自定义复杂结构，调试时用UA Expert这类工具浏览一遍节点树，再决定采集哪些节点，能省很多时间。

4.3 OPC UA PubSub与MQTT：云边协同的变体

传统OPC UA是客户端去服务器拉数据，PubSub模式下则是服务器主动把数据“广播”出去，传输层可以基于UDP，也可以基于消息中间件如MQTT。这正好解决了PLC数据上云问题：现场边缘网关或PLC内置的OPC UA服务器，把数据发布到云端MQTT Broker，云端应用订阅即可。

我在实际项目里，通常让OPC UA服务器保留本地实时采集通道，同时用另一个轻量发布器把聚合后的数据发布到MQTT主题。主题设计要有讲究，比如factory/{产线}/{设备}/telemetry，带上时间戳和设备ID，云端解析简单很多。注意MQTT的QoS级别，PLC到网关的链路相对可靠，选QoS 1就好，QoS 2的性能开销和重发机制在敏感环境里反而会带来麻烦。

4.4 DDE/NetDDE：还没死透的历史交换方式

DDE是老Windows里的进程间通信，通过消息广播交换数据，Excel里经常用。NetDDE则是把它扩展到网络。早期很多MES报表系统、实验数据系统就是通过DDE从SCADA或专用驱动里拉PLC数据，现在看这套机制效率低、不稳定，且有很大的安全隐患，Windows厂商早就不建议开放NetDDE端口。

但存量系统还活着。如果你接手一个用DDE的老项目，我的建议是不要在这上面扩展功能，只做“维持运行”。把DDE采集的数据流向新系统时，尽量在中间加一层缓冲，避免DDE消息抖动导致新系统数据断档。如果条件允许，尽早规划替换为OPC UA或数据库对接。

4.5 数据库直读与中间表：最“简单粗暴”的对接方式

有些PLC或网关支持直接连接关系数据库，比如把产量写入SQL Server的中间表，MES系统再去读；或者上位机直接查询PLC侧维护的数据表。这种方式编程序最简单，也最容易被业务系统接受。

但要注意几点：数据库连接需要占用PLC侧资源，频繁读写会影响PLC的扫描周期，所以只适合低频数据，比如每小时一次或每分钟一次。中间表设计时要加“数据处理状态”字段，MES读走一条记录后要能标记“已处理”，避免重复统计。还要设置连接超时和重连逻辑，数据库重启了，PLC侧不能因此死机。我的经验是，在PLC侧不要把数据库访问逻辑写得太复杂，所有SQL都封装成一个可配置的功能块，换数据库类型时只改连接字符串和映射表。

4.6 API/SDK二次开发：原厂能力的边界

如果标准协议读不到深层数据，比如诊断区、系统状态、特定DB块结构，最后的手段是调用原厂提供的API或SDK。很多PLC厂商提供C/C++、C#、Python的开发库，或者开放底层通信驱动。

这确实是“能力边界最深”的方法，能读到别人读不到的东西，但代价是绑定生态。API版本跟着固件走，PLC一升级，采集程序可能就要重新编译；许可证机制也可能限制并发数。我的建议很明确：能用标准协议（Modbus、OPC UA）解决的需求，不要为了一点便利去绑定SDK；只有标准协议确实覆盖不到，比如要读某个控制器内核诊断数据，再考虑SDK。而且用SDK的项目，程序和依赖库要一并归档，防止换人之后搞不清版本匹配关系。

4.7 内置Web服务器：看一眼数据真的不难

现在的PLC很多内置了Web服务器，浏览器输入IP地址就能打开状态页，部分还提供JSON或XML接口，用HTTP GET就能读到变量。这种方式的优点是没有额外软件成本，适合做现场快速诊断、设备状态看板、临时调试。

但它不适合做正经的数据采集平台，因为内置Web服务的并发能力、数据刷新率、接口能力都有限，工业现场多系统长期高频访问会拖慢PLC的处理。我一般只建议用Web接口做“人肉巡检”和临时排障，正式采集还是走OPC UA或Modbus。如果确实要用，尽量只读不写，会话超时设置短一点，避免浏览器把会话占住不放。安全方面，要确认页面默认账号密码已经改掉，不能暴露在办公网里裸奔。

5. 文件、无线与硬件：最后七种方法补齐全景图

5.1 FTP/SFTP文件转储：老旧设备最后的体面

有些老PLC没有以太网通信模块，但支持把数据写成CSV、日志文件或配方文件，再通过FTP或共享目录传到上位机。这在离线设备、间歇式产线、故障追溯场景里非常实用——数据哪怕延迟一天，只要能把历史追回来就够用。

实操时最需要注意的是“文件完整性”。如果PLC一边写文件一边被你拉走，拉到的很可能是一半的坏文件。稳妥做法是PLC侧先写临时文件，写完再重命名成正式文件名；采集端也先下载到本地临时目录，确认文件大小稳定后再移动。编码问题也常遇到，国内PLC写的CSV常用GBK编码，Python或新平台读取容易乱码，统一转换为UTF-8再入库。文件里记得带上设备ID和批次号，多设备文件混在一起时才有办法区分。

5.2 MTConnect：数控设备圈的“普通话”

MTConnect是面向数控机床、机器人等设备的开放式数据采集标准，底层用HTTP加XML，通过Agent和Adapter两层结构实现。数控系统侧跑一个Adapter，把控制器内部数据翻译成标准格式，Agent对外提供RESTful API，上位机只需要请求URL就能拿到设备状态、主轴负载、进给速度等数据。

在机加工车间做设备联网，MTConnect几乎是绕不开的选项。它和PLC的协议栈完全不同，更像“设备的Web服务”。实施时要确认数控系统厂商是否提供官方Adapter，没有的话就要自己解析控制器协议，工作量会明显上升。数据格式是XML，解析方便但字段特别多，采集程序要做字段白名单过滤，只保留MES需要的部分，不然存储压力会失控。

5.3 4G/5G DTU透传：没有网线也能远程采集

对分散在多个地点的设备站、泵站、风电光伏场站，拉光纤或网线成本太高，4G/5G DTU是首选。DTU把串口或以太网数据封装成IP包，通过运营商网络送到云端服务器或上位机，实现远程数据采集和控制。

选DTU时重点关注三件事：注册包和心跳包的配置，这决定了它能稳定连上平台；APN设置，物联网卡通常要用专用APN；断线自动重连机制，现场电源不稳时DTU要能自恢复。数据量方面，Modbus RTU轮询几十台设备，每月流量很小，但要警惕心跳包太频繁造成的无效流量。远程采集的网络时延通常在几十到几百毫秒，只适合监控级数据，不适合做运动控制。

5.4 NB-IoT：低功耗窄带物联网

NB-IoT和4G/5G最大的区别是“窄”，速率低，但穿透能力强、功耗极低、模组便宜，适合那些数据量很小、上报频率很低的设备，比如水表、气表、振动传感器、环境监测仪。工业现场有些PLC数据只需要每天上报几次，或者只在异常时上报一次，NB-IoT就很合适。

不过NB-IoT对时延和数据量容忍度很低，不要拿它做毫秒级采集，也不要一次上报几百个参数。接入时通常要走运营商的物联网平台，再转发到自己的应用，平台侧要处理设备生命周期管理。NB-IoT频段在某些厂房深井、地下室可能信号也不够，需要先做信号测试再批量部署。

5.5 LoRa无线数传：自建局域无线网络

LoRa的亮点是自组网。工厂园区里自己架几台LoRa网关，每个PLC设备挂一个LoRa数传终端，数据通过网关汇聚到本地服务器，全程不依赖运营商，没有流量费。扩频技术让它有很强的抗干扰能力和穿透能力，适合厂房里到处都是金属结构、WIFI覆盖不稳定的环境。

LoRa的速率同样不高，而且空中信道是共享的，节点越多，每个节点能分到的时隙越少。实测下来，可靠上报间隔基本在秒级，适合温度、压力、状态量采集，不适合抖动控制或密集高速采集。组网时要规划好频点、扩频因子和网关接入数量，同一个网关下终端过多会明显增加冲突概率。为降低现场无线丢包的影响，采集程序最好在LoRa节点侧配置本地缓存和重发机制，网络恢复后自动补报。

5.6 I/O硬接线采集：最原始但最可靠的采集方式

当PLC实在不开放任何通信接口，或者这台设备的通信协议早已失传，还有最“硬核”的办法：直接从I/O点接线采集。数字量输出接一个中间继电器，继电器触点接到采集器的DI通道；模拟量输出如果走4-20mA或0-10V，直接引到采集器的AI通道。

I/O硬接线的优点是可靠、直观、不依赖协议，缺点是布线工程量大、只能采集I/O信号，采集不到设备内部参数。做这种方式时，隔离一定要做到位。DI通道用光电隔离，继电器线圈不要从PLC侧取电，防止干扰回灌；模拟量信号线用屏蔽双绞线，屏蔽层单端接地；接线端子要留足够空间，方便现场万用表测量。还有一点很关键，I/O采集器和PLC的供电最好分开，避免现场强电故障把两边一起烧掉。

5.7 协议转换网关：把散装方法汇聚成统一出口

第25种也是我最常用的一种：协议转换网关。前面提到的很多现场总线、实时总线，最终都汇总到这种设备上，统一转成Modbus TCP、OPC UA或MQTT发给上位机。它相当于一个“万能翻译官”，把车间的多国语言翻译成英语。

选型时重点看几个指标：支持的从站协议数量，现场实际需要接入几路总线；标签映射容量，不能只映射十几个变量；数据缓存能力，断网时缓存能存多久；链路隔离与访问控制。我自己做项目时，习惯把网关放在控制网和工厂信息网的边界上，让PLC控制网和办公网、云平台物理隔离，这样既能上网关采数，又不会把控制网暴露到外部。网关配置好后，别忘了做一轮“停电掉线恢复”测试，看看重新上电后映射关系是否还在、轮询是否会自动恢复。这一步看起来不起眼，却能避免很多半夜值班电话。

这套25种方法的清单，是我在这些年项目里一点点拼出来的。每一种方法单独拿出来都不算复杂，难的是判断“什么时候该用它”。我自己的习惯是接到项目先画一张链路图，把PLC型号、支持协议、网段、目标系统全部标上去，再倒推采集方案。最后再提醒一句：不管你选了哪一种，动手前一定和设备方确认好“允许碰哪些点、能不能写、断网重连策略是什么”——数据采不到可以再想办法，把生产系统搞停了才是大事故。