设备数据采集三大方案：协议直采、网关接入与IO采集详解

车间里的设备五花八门，摆在自动化工程师面前的第一道坎，从来不是"要不要做数字化"，而是"设备的数据到底怎么拿出来"。我这两年跑了十几个工厂的技改项目，发现大家问得最多的就是一句：设备数据采集到底有哪几条路？今天不绕弯子，把三种主流方案——协议直采、网关接入、IO采集——从原理到落地、从选型到踩坑，一次讲透。

不管你是做MES、做能耗管理、做设备OEE，还是单纯想远程看一眼设备状态，数据采集都是躲不掉的前置工作。而选哪条路，取决于设备本身"开口说话"的能力。理解了这一点，后面所有方案都不难。

1. 先从物理层聊起：设备凭什么能告诉你"我怎么了"

很多人一上来就问"用什么采集方案"，这是个伪问题。正确的问法是：我现场的设备，能通过什么方式把状态吐出来？搞清楚这个，方案自然就浮出来了。

1.1 会"说话"的设备：通信接口与协议

近十多年出厂的大多数设备，哪怕是一台普普通通的变频器、温控表，都会带至少一个通信口。最常见的是RS485串口、以太网口，高端一些的有光纤口、USB口。这是硬件层面的"嘴巴"。

光有嘴还不行，还得有语言。工控设备通信靠的是协议族。Modbus算是工业界的通用语，西门子的S7协议是自家设备专属语，OPC UA则是跨厂商的"普通话"。

能通过协议直接读取数据的设备，是你最省心的对象。无论是PLC、仪器仪表、伺服驱动器还是智能电表，只要手册里写清楚了"支持Modbus/OPC UA/S7"等协议，就可以直接编程序去问它要数据。这也是"协议直采"方案的前提。

1.2 不会"说话"的设备：只有IO信号的"哑巴设备"

但你千万别以为所有设备都这么配合。很多老设备、专用设备，甚至是一些小型非标自动化机台，压根没通信口。它们对外输出的就是干接点信号、继电器触点、模拟量电压电流。举个典型例子：一台老式的液压机，控制器上只有一个"运行中"继电器触点、一个"故障"触点、一个油温传感器输出的4-20mA信号。

这种设备怎么采集？把它的触点接入一个输入模块，把油温模拟量接入一个模拟量采集模块，这些信号就变成了数字世界的0和1、数值和工程单位。这就是IO采集方案存在的意义。

1.3 想说但不好说的设备：异构系统的"中间翻译官"

还有一类设备处于中间态：它们有通信口，也支持某些协议，但数据格式混乱、协议分散。比如车间里既有Modbus设备、又有Profibus设备、还有走私有协议的老旧系统，每个设备要单独写驱动开发，工作量巨大。

这时候需要一种"翻译官"设备——网关。它一头接设备的各类协议，另一头按你指定的标准协议输出，把乱七八糟的数据统一成一种格式，接到你上层的SCADA、MES或其他平台里。

所以，所有采集方案不外乎这三条：能说话的，直接问它要数据；不能说话的，通过IO信号硬采；说话听不懂的，找个网关翻译统一。后面每一条路，我拆开细讲。

2. 协议直采：最直接，但细节决定成败

协议直采，简单说就是采集程序直接和设备通信。你的上位机软件、PLC、或者数据采集网关，用设备支持的协议，按寄存器地址或数据节点去读取。

2.1 我实际用到最多的几种协议

不同行业、不同设备厂商，主流的通信协议差异不小。这里列几个我项目里碰得最多的：

• Modbus RTU/TCP：工业界最普及的"通用语"。变频器、智能电表、温控器、流量计、大部分国产仪表都支持。RTU走RS485串口，TCP走以太网。寄存器分线圈（0x）、离散输入（1x）、输入寄存器（3x）、保持寄存器（4x），初学容易混淆，但用熟了就发现它真简单。
• S7协议（S7comm/S7comm-Plus）：西门子S7-200/300/1200/1500 PLC的专属协议。S7-1200/1500默认走S7comm-Plus，老一代第三方库直读容易受限，往往要打开PLC的"允许来自远程对象的PUT/GET通信访问"选项。
• OPC UA：跨厂商跨平台的标准通信规范，服务器/客户端架构，安全性好，数据建模丰富。现在新建的大型项目，尤其汽车、制药、半导体行业，OA化程度高，OPC UA基本是标配。
• EtherNet/IP、PROFINET、CC-Link：不同厂商主导的工业以太网协议。如果你要采集的设备是AB PLC，大概率走EtherNet/IP；是西门子PLC，PROFINET或S7都可能；是三菱产线，CC-Link或MC协议常见。

2.2 直采前必须确认的几项参数

做直采，第一步不是写代码，而是翻设备手册。我见过太多人上来就乱试寄存器地址，折腾一整天最后发现是变频器通信参数没设置。直采前，至少要确认这几项：

• 通信接口：RS485还是以太网。RS485需要确认波特率（9600、19200、38400等）、数据位（通常8）、校验位（无、偶、奇）、停止位（1或2）、设备地址（1-247）。
• 寄存器地址与数据类型：以Modbus为例，对应"运行频率"的寄存器地址是多少，是16位还是32位，是否带符号，高低字节顺序如何。这一点极关键，错了读出来的数据就是天书。
• 访问权限与安全策略：S7-1200/1500是否开启了PUT/GET；某些保护型PLC需要证书或用户名密码；OPC UA要考虑安全策略、证书信任关系。
• 扫描周期与读写频率：直采时你要决定多久轮询一次。一般生产参数如电流、温度，1-5秒一次足够；快速报警联锁信号，则需要更快甚至用订阅方式。

2.3 轮询策略：别把所有点位一锅轮询

刚开始做采集的同学最容易犯的错，就是贪多求全，一次性把PLC里所有寄存器全部轮询一遍，结果导致数据刷新慢、通信负载高。实际项目里，我的做法是给点位分级：

• A级点（报警、急停信号）：订阅或最短周期轮询，比如500ms以内，数量控制在少数关键点。
• B级点（生产参数、运行状态）：1-2秒轮询，覆盖核心设备状态。
• C级点（能耗统计、温度趋势）：5-15秒轮询，不需要实时性。

这样分配之后，同样的通信总线能带更多的设备，不容易出现通信拥堵。对RS485总线来说尤其如此，因为串口是半双工、一问一答，总线上设备越多、点越多，轮询越慢。实测一个9600波特率的RS485总线，带10块仪表、每块读10个寄存器，一轮下来可能要3-5秒。如果你的上层应用要1秒刷新一次，就得考虑拆分总线或者改用网关主动采集。

2.4 直采的三大常见坑

协议版本坑。同样的"Modbus"，有些厂商的寄存器地址是0-based，有些是1-based；西门子的数据块寻址和第三方的Modbus映射也经常对不上。处理办法：先在设备侧用手持调试工具或厂商软件读一次，确认真实值，再对着你的采集程序一条一条校准。

字节序坑。32位浮点数在Modbus里怎么存？有的设备是ABCD，有的是CDAB，还有的是BADC。读出来变成几十万的大数，大概率就是字节序没调对。建议采集程序里把字节序做成可选配置，现场调试时切换最快。

并发连接坑。部分PLC的通信连接数是有限的。S7-1200默认的PUT/GET连接资源通常有限，有些老型号甚至只有3个。你上了3个采集软件同时去连，第四个就废了。上系统前要算好连接资源，或者通过网关统一转发，避免多个系统直接扑上去。

3. 网关接入：把复杂留给网关，把统一交给平台

当设备类型多、协议杂、点位分散的时候，逐个用上位机去直采会变成一场维护噩梦。这时候网关的价值就体现出来了。

3.1 网关到底在做什么

网关本质是一台小型的工业计算机，只是它的本职不是算数据，而是"接进来、转出去"。

• 接进来：通过RS485/RS232/以太网口，用Modbus RTU、S7、OPC UA等协议把各设备的数据读上来。
• 转出去：把读到的数据整理成统一的格式（通常是JSON/MQTT消息或OPC UA Server），通过以太网、Wi-Fi、4G/5G发送到上层系统。

很多边缘网关还能做一层轻量处理：本地缓存、数据过滤、阈值判断、边缘计算。比如你不想把所有原始温度值都上云，只想在超过80度时发一个报警，网关本地就能判断和推送，避免大批无意义数据占用带宽。

3.2 网关选型：看接口、看协议库、看边缘能力

市面上网关产品非常多，从几百块的"DTU"到上万块的"边缘计算网关"都有。我的选型经验是看三项：

接口数量与类型。现场是RS485设备多，还是以太网设备多？是否需要同时接多路RS485？有些设备走RS232（老式仪表），要确认网关有没有对应串口。注意：RS485和RS232不同，不能只靠转接头解决。

协议库覆盖程度。网关自带协议驱动数量是关键。好的网关往往有上百种驱动，Modbus、S7、OPC UA、三菱、AB、欧姆龙、台达全都有，直接选型对应驱动就能采集。协议库越丰富，你越不用自己写驱动，也就越省心。

边缘计算与存储能力。网关CPU性能、内存大小、是否支持SQLite本地存储、是否支持规则引擎。如果你的场景需要断网时也把数据存下来，等网络恢复再补传，网关的本地存储能力就是硬指标。

3.3 数据上送：MQTT、HTTP还是OPC UA

网关采集到数据之后，怎么发给平台，也是一门学问。

• MQTT：目前最推荐的上送方式。轻量、基于订阅发布、支持断线重连和遗嘱消息，非常适合工业设备数据上云。用JSON或二进制payload传数据，平台端用MQTT Broker接收。
• HTTP/HTTPS REST API：适合对接第三方平台时使用，网关定时把数据POST到平台的API接口。注意鉴权、超时重试机制。
• OPC UA：如果上层组态软件是传统SCADA，或者对数据安全性要求高，网关可以直接充当OPC UA Server，上层系统作为客户端去订阅即可。

实测下来，MQTT在断网重连和弱网环境下的表现最稳。我做过一个用4G网络的项目，MQTT配合本地缓存，断网2小时数据也没丢，恢复后自动补传，上层平台几乎无感知。

3.4 现场部署网关的4个实操细节

1. IP规划要提前做。每个设备和网关的IP必须在同一网段或做好路由，否则采集程序连不通。提前做一张IP分配表，附上设备名称、IP、端口、协议和寄存器范围，现场调试会快很多。

2. 串口接线容易错。RS485是A/B两线，有些设备标的是D+/D-，有些是A/B，还有485+/485-，接线顺序错了不仅通信不上，还可能损坏模块。务必用万用表量好电压极性再接。

3. 网关别放在配电柜里贴着变频器。虽然有抗干扰设计，但强电柜里的变频器、接触器干扰太大，实测RS485通信丢包率会明显上升。能单独装就单独装，不能的话也要尽量远离干扰源，并选屏蔽双绞线，屏蔽层单端接地。

4. 固件和协议库要升级。买网关的时候要问清楚固件更新频率，现场遇到过某个老版本协议库不兼容新固件的仪表，升级协议库后就好了。这属于非常"隐形"的坑，但很常见。

4. IO采集：没有通信协议，照样把信号变成数据

聊完协议直采和网关，还得面对那部分"哑巴设备"。在这个环节，IO采集是唯一能解决问题的路。

4.1 先分清三种IO信号

工控设备能对外输出的信号，基本可以归成三类：

• 开关量（数字量/DI）：只有0和1，比如继电器触点是否闭合、接近开关是否触发。接入数字量输入模块，采集到的就是0或1，对应设备的启停、到位、报警等状态。
• 模拟量（AI）：连续的电压、电流信号，最常见的是4-20mA电流信号、0-10V电压信号。传感器（压力、温度、液位、流量）把物理量变成线性电信号，采集模块把它AD转换成一个数值，再通过量程换算变成工程单位值。
• 脉冲量（PI）：连续的脉冲信号，常用于电表、流量计、编码器。采集模块通过计数器统计脉冲数，换算成累计电量、累计流量或位置。

4.2 硬件怎么选：采集模块、PLC扩展还是IO盒子

实操中，IO采集的硬件选型有三条路线：

• 远端IO模块：比如研华ADAM/ICP DAS系列、泓格、国产的众多以太网IO模块，直接采集IO信号后转成Modbus TCP/RTU协议，上层系统通过Modbus轮询即可。这类模块成本低、部署灵活，非常推荐在改造项目里用。
• PLC扩展IO：如果你现场已经有PLC，直接用PLC的IO扩展模块采集，然后上位机通过PLC原有协议读取。好处是不增加新的硬件节点，坏处是占用了PLC程序、扫描周期和通信资源。
• IO采集盒子（一体机）：集成了数字量输入输出、模拟量采集、继电器输出等，往往带以太网口，配置界面友好，适合小点位场景。

我个人的偏好是：改造项目优先使用支持Modbus TCP的以太网IO模块。接线少、不用考虑串口轮询延迟、调试时浏览器打开配置页面改一改就行。下面是一个典型接线方案。

4.3 接线与量程换算：坑最多的环节

IO采集最坑的永远不是采集，而是"信号质量"和"量程换算"。

4-20mA信号：模拟量模块常见的是接受4-20mA，外接24V电源、传感器串联回路。需要注意：传感器是两线制还是四线制，两线制直接串在回路里，四线制要单独供电再输出信号。接错了电流回路是环不起来还是直接烧保险，都有可能。

量程换算是另一大坑。比如压力变送器量程是0-10MPa，输出4-20mA。你模块读到的原始值可能是0-65535（16位），也可能是0-4000（12位），需要先把原始值换算成mA，再换算成MPa。

算法很简单，但很容易在缩放上出错：

假设模块读到的原始值为raw，0-65535的满量程对应0-20mA（或4-20mA），则：

code复制mA = (raw / 65535) * 16 + 4
MPa = (mA - 4) / 16 * 10

注意：很多设备出厂把4-20mA映射到0-65535的整数范围，因此计算时是"当前mA = raw/6553516 + 4"，而不是"raw/6553520"。不少现场调试人员忘了加4mA的偏置，导致压力显示比实际低25%，第一次排查的时候容易懵。

此外，还要区分模块有没有自带变送器电源。有些模块的AI口自带24V馈电，你不需要额外接线电源；有些则必须外部供电。选型的时候一定要看清楚，否则到了现场会发现信号怎么都不对。

4.4 IO采集与协议直采混用的典型场景

实际项目里，很少会出现"全部靠IO采集"的情况，更多的是混合方案。

举个例子：一台注塑机，控制器支持Modbus TCP，可以读出温度、压力、周期等参数；但它的冷却水系统是独立的老式电控箱，只有一组水泵运行反馈触点、一个水温表（4-20mA输出）和一个流量开关。这种情况下，最合理的做法是：注塑机本体用协议直采，冷却水系统加一个远程IO模块，采集水温水泵状态，然后通过Modbus TCP把IO数据也并入统一采集网络。这样一来，整个设备的数据就能汇总到同一个平台，实现真正意义上的"整机数字化"。

5. 三种方案如何配合成一张网

把零散方案串成一张网，才是工厂数据采集能力的最终形态。这也是我从一个车间改造项目里总结出的路径。

5.1 最小可行架构：单车间级

如果你只负责一个车间，设备数量在几十台以内，不需要很复杂的平台，那架构可以非常轻：

• 支持协议的设备：直接用上位机软件或边缘网关做协议直采。
• 无协议的老设备：加IO采集模块，模块本身转成Modbus TCP，再由同一台网关采集。
• 网关把所有数据通过MQTT推送到一个轻量看板或MES系统。

这个架构从硬件到软件，最快几天就能跑通。我们在一个机加工车间就是这么干的，两台网关加四个广达IO模块，覆盖了30多台设备，实现OEE实时统计和故障报警，总成本控制在几万块以内。

5.2 整厂级架构：从车间到企业级平台

当规模扩展到整个工厂、多个车间、不同厂区时，采集架构需要更清晰的层级：

• 现场层：设备、IO模块、传感器，保证数据能被采到。
• 接入层：各车间的边缘网关设备。网关做协议转换、边缘采集、本地缓存。
• 汇聚层：工厂级的数据采集平台或消息中间件，比如基于MQTT/Kafka的数据接入服务，把各车间网关的数据统一汇总。
• 应用层：MES、SCADA、能源管理、设备管理系统等，从汇聚层拿数据做分析和展示。

这种分层的好处是：每个车间独立运行，网关挂了只影响本车间，不会拖垮整厂平台；各车间的协议和点位也被封装在网关层，上层应用只看到统一的数据模型，不需要关心底下是什么设备。

5.3 点位规划与采集频率设计

设计整网时，一个最关键的表格是"点位清单"或者说"测点台账"。没有它，后面全乱。

我在项目中会先做一张这样的表：

这张表既是施工图纸，也是后期排障的索引。点位类型、采集方式、扫描周期如果不定义清楚，等系统上线再改，代价是非常大的。

6. 到了做决策的时候：我这十几年的选择逻辑

最后回到最核心的问题：面对一台设备，我到底该用协议直采、网关接入、还是IO采集？我的决策逻辑很简单，分四步。

第一步：看设备有没有通信接口。没接口，直接走IO采集，不用纠结。

第二步：看协议是否常见。支持Modbus RTU/TCP、S7、OPC UA这些主流协议，优先协议直采；如果是私有协议、老型号协议、或者厂商已经不维护的协议，走网关，让它去处理复杂的协议转换。

第三步：看改造范围和工期。设备少、工期紧，协议直采最省事；设备多、协议杂、要统一上平台，网关接入是性价比最高的选择。IO采集只用来补漏，不要当成主力。

第四步：算投入产出比。协议直采的软件开发和调试成本主要在人工；网关采购有硬件成本但能省大量开发调试时间；IO采集的材料成本低但需要大量施工接线和排障，点位多的时候人工成本会很高。

从我个人的经验看，大部分工厂是三类方案混合使用。能直采的直接采，采不了的用网关兜底，网关也搞不定的，上IO采集。

另外，真的建议所有的数据采集项目，都先把"底层设备能提供什么"调查清楚，再定方案。别拿了一套先进的平台，结果到了现场发现设备不支持，那是整个项目最大的灾难。

最后提一个小技巧：无论选哪种方案，都记得在设备侧和采集侧分别做一套数据校验。设备上显示的数值和采集系统显示的要能对得上。这看起来是笨办法，但无数调试到深夜的问题，最后都是靠这个笨办法找到根源的。