在制造业数字化项目里，很多需求表面上看起来很简单：
- 想把设备数据接到 MES
- 想做车间看板
- 想统计 OEE
- 想做设备报警
- 想做工艺追溯
- 想给后续 AI 分析准备数据底座
但真正进入实施阶段后，第一道绕不过去的问题通常是：
设备数据到底该怎么采？
很多项目失败，不是因为没有预算，也不是因为没有系统，而是一开始就把“设备数据采集方案”想得太简单。
有人觉得只要“买个网关”就能全部搞定；有人觉得只要“连 PLC”就可以；还有人觉得所有设备都能统一走 OPC。
现实往往不是这样。
同一个工厂里，可能同时存在：
- 新设备，支持标准协议
- 老设备，只有简单 IO 信号
- 不同品牌 PLC
- 厂商私有控制器
- 有些设备开放变量表，有些完全不开放
- 有些需要实时参数，有些只需要状态和产量
所以，工厂设备数据采集并不存在一种万能方案。
真正合理的做法，通常是根据设备条件、业务目标、预算和实施周期，选择合适的技术路线。
本文就从工程实践角度，把工厂设备数据采集的主流方案一次讲清。
1. 为什么“设备数据采集方案”不能一刀切
在讨论方案之前，先要明确一件事：
工厂设备数据采集不是一个标准化程度很高的纯软件问题，而是一个强现场、强设备差异、强业务约束的系统工程问题。
之所以不能一刀切，主要有几个原因。
1.1 设备异构严重
一个车间里，可能会同时存在：
- 西门子 PLC
- 三菱 PLC
- 欧姆龙 PLC
- 台达 PLC
- 汇川 PLC
- Modbus 仪表
- CNC 系统
- 注塑机专用控制器
- 非标自研设备
- 无 PLC 的老旧设备
这些设备的通信能力和开放性差异非常大。
1.2 业务目标不同
有的项目只想知道：
- 设备是否运行
- 当前产量
- 是否报警
有的项目则需要更深的数据：
- 工艺参数
- 周期时长
- 配方切换
- 参数修改记录
- 故障代码
- 批次追溯数据
目标不同，采集方案自然不同。
1.3 预算与周期不同
有的项目要求：
- 两周内快速上线
- 先覆盖 20 台重点设备
- 能出看板即可
有的项目要求：
- 全厂统一接入
- 后续接 MES、QMS、ERP
- 数据结构标准化
- 支持长期扩展
这两类项目，显然不能采用同样的实施策略。
1.4 可获取的数据边界不同
有些设备理论上“能采”，但实际上拿不到：
- 地址表
- 协议文档
- 厂商授权
- 关键变量定义
这时候，技术上就必须退一步，选更可落地的方案。
所以，一个更准确的说法是：
工厂设备数据采集方案，不是先选技术，而是先判断设备条件、业务目标和可落地边界。
2. 工厂设备数据采集的主流方案有哪些
从现场实施经验来看，常见的设备数据采集方案主要有六类：
- 协议直采
- 工业网关采集
- OPC 采集
- IO 信号采集
- 外挂传感器采集
- 自动采集 + 人工补录结合
下面分别展开。
3. 方案一：协议直采
协议直采，通常是指通过设备本身支持的通信协议，直接读取 PLC、控制器、仪表或 CNC 系统中的数据。
常见包括：
- Siemens S7
- Mitsubishi MC 协议
- Omron FINS
- Modbus TCP
- Modbus RTU
- OPC UA
- EtherNet/IP（部分场景）
- CNC 厂商协议
- 注塑机控制器协议
3.1 工作方式
通常由上位机、采集程序或边缘网关主动发起通信，请求读取指定地址、寄存器、变量或标签。
3.2 适用场景
适合：
- 设备通信能力较好
- PLC 型号明确
- 协议可获取
- 地址表可确认
- 希望采集较丰富数据
例如：
- 状态
- 产量
- 工艺参数
- 报警码
- 运行模式
- 配方号
- 周期变量
3.3 优点
- 数据维度丰富
- 实时性较好
- 精度高
- 扩展性强
- 更适合后续做 MES、工艺分析、AI 建模
3.4 缺点
- 依赖协议和点位信息
- 不同品牌接入复杂度不同
- 需要处理地址变化、变量命名不一致等问题
- 某些设备虽有协议，但实际开放程度有限
3.5 典型结论
如果设备条件允许，协议直采通常是优先级最高的方案。
因为它最接近设备内部真实数据，后续治理和扩展空间也最大。
4. 方案二：工业网关采集
工业网关采集，本质上并不是一种完全独立于协议直采之外的方案。
更准确地说，它是把“协议接入、边缘处理、数据转发”封装到一个现场设备或边缘节点中。
工业网关通常承担几个角色：
- 连接不同品牌设备
- 完成协议解析
- 做数据缓存
- 做变化上报
- 做边缘统计
- 向 MQTT、HTTP、数据库、消息队列等上送数据
4.1 适用场景
适合：
- 现场设备品牌多
- 需要统一接入
- 需要本地边缘计算
- 需要断网缓存
- 需要对接多个上层系统
4.2 优点
- 适合多协议统一管理
- 部署相对灵活
- 可以把边缘逻辑前置到现场
- 更适合大规模设备接入
- 对上层 MES / 平台更友好
4.3 缺点
- 网关能力差异很大
- 如果网关只是“转发器”，实际价值有限
- 驱动兼容能力决定项目成败
- 边缘逻辑设计不当，可能导致数据混乱
4.4 一个容易被误解的点
很多人把“买了网关”理解成“问题解决了”。
其实不是。
真正决定效果的，不只是有没有网关，而是网关是否具备这些能力：
- 稳定的协议驱动
- 现场调试能力
- 数据模型映射能力
- 变化上报能力
- 边缘统计能力
- 状态识别能力
- 缓存与重传能力
否则，网关只是把复杂性换了个位置。
4.5 典型结论
当工厂设备品牌多、项目需要扩展、后续要对接多个业务系统时，工业网关 + 边缘处理通常是最实用的主流方案。
5. 方案三：OPC 采集
OPC 是工业领域较经典的数据交换方式，常见有：
- OPC DA
- OPC UA
其中现在更常见的是 OPC UA。
5.1 工作方式
设备或中间件提供 OPC Server，采集端作为 OPC Client 去订阅或读取变量。
5.2 适用场景
适合：
- 设备本身支持 OPC UA
- 工厂已有 OPC 中间层
- 自动化体系较规范
- 对接标准化要求较高
5.3 优点
- 标准化程度高
- 变量管理相对清晰
- 跨系统对接方便
- 对已有自动化环境友好
5.4 缺点
- 并不是所有设备都支持
- 很多老设备无法直接走 OPC
- 现场实际变量质量和命名仍可能混乱
- 解决不了“设备本身不开放”的问题
5.5 典型结论
OPC 是很好的标准化接入方式，但它更适合“已经具备一定基础”的现场。
它不是万能入口，也不能替代所有底层数采方案。
6. 方案四：IO 信号采集
这是老旧设备改造里非常常见的一条路线。
当设备无法直接读取内部变量时，可以从外部信号下手，例如：
- 运行灯
- 报警灯
- 急停信号
- 节拍脉冲
- 继电器输出
- 开机信号
- 停机信号
通过 IO 模块、采集板卡或远程 IO，把这些离散信号采上来。
6.1 适用场景
适合：
- 老旧设备
- 无 PLC 或 PLC 无法开放
- 只需要状态、节拍、简单计数
- 项目预算有限
- 需要快速上线
6.2 优点
- 落地快
- 对设备侵入小
- 成本相对可控
- 对老设备很实用
6.3 缺点
- 数据维度有限
- 拿不到深层工艺参数
- 需要额外做状态识别逻辑
- 对接线和信号判断依赖较高
6.4 常见误区
IO 采集不是“低级方案”，它在很多老设备场景下反而是最现实的方案。
真正的问题不在于是不是 IO，而在于：
- 信号选得对不对
- 状态映射逻辑准不准
- 节拍识别算法稳不稳
6.5 典型结论
对于大量老设备、非标设备、无协议设备，IO 采集往往是成本和效果之间最平衡的路线。
7. 方案五：外挂传感器采集
当设备内部信号拿不到、IO 也不方便动时，就可能采用外挂传感器方案。
例如：
- 电流传感器识别设备是否运行
- 光电传感器识别工件通过
- 振动传感器判断加工状态
- 接近开关判断动作次数
- 温度传感器补充环境与工艺信息
7.1 适用场景
适合：
- 无法进入设备控制系统
- 不允许改 PLC / 接 IO
- 只需要判断运行、停机、节拍等基本状态
- 需要快速做试点验证
7.2 优点
- 不依赖设备协议
- 对老旧设备适应性强
- 部署灵活
- 可用于验证阶段
7.3 缺点
- 采的是“外部特征”，不是设备原始业务数据
- 容易受安装位置、干扰、现场环境影响
- 数据解释成本高
- 维护成本可能偏高
7.4 典型结论
外挂传感器更适合作为补充方案或替代方案，而不是默认首选。
但在现场受限条件下，它很可能是唯一能快速起步的路径。
8. 方案六：自动采集 + 人工补录结合
这类方案经常被低估，但在很多项目里非常重要。
因为真实生产现场有不少关键数据，设备本身并不会自动给出，例如：
- 停机原因
- 换模原因
- 不良类型
- 工单切换
- 班次信息
- 异常备注
这些数据如果完全不补，后续分析会缺少业务上下文。
8.1 适用场景
适合几乎所有工厂，尤其是：
- 需要做生产分析
- 需要做停机分析
- 需要做质量追溯
- 需要做工单关联
8.2 优点
- 能补齐设备无法自动提供的信息
- 更容易形成业务闭环
- 更适合管理分析
8.3 缺点
- 依赖现场执行
- 需要设计简洁的人机交互
- 如果录入流程太复杂，容易失真
8.4 典型结论
一个真正可用的数采系统，通常不是“100% 自动化”，而是：
自动采集负责抓设备事实，人工补录负责补业务语义。
9. 这些方案该怎么选
前面讲了六种方案，真正落地时，关键不是“哪个最先进”，而是“哪个最适合当前场景”。
可以从四个维度来判断。
9.1 先看设备开放性
如果设备有明确协议、点位可拿、通信条件可满足，优先考虑：
- 协议直采
- 网关接入
- OPC 接入
如果设备不开放或拿不到点位，再考虑：
- IO 采集
- 外挂传感器
9.2 再看业务目标
如果只想做：
- 运行/停机监控
- 简单产量统计
- 稼动率分析
那 IO 或传感器方案可能就足够。
如果还想做：
- 工艺追溯
- 参数越限报警
- 配方关联
- 周期精细分析
- AI 建模
则更适合协议级数据采集。
9.3 再看扩展要求
如果后续要对接：
- MES
- QMS
- ERP
- OEE
- BI
- AI 平台
那建议尽量从一开始就考虑：
- 统一数据模型
- 边缘治理能力
- 稳定的数据转发机制
这时候，工业网关 + 协议采集通常更合理。
9.4 最后看实施条件
包括：
- 是否能停机调试
- 是否能接入产线网络
- 厂商是否配合
- 是否能拿到图纸和点位表
- 项目周期是否紧张
很多时候，最优方案不一定是最理想方案，而是当前约束下可交付的方案。
10. 一个更实用的判断原则：先求可用，再求完美
设备数据采集项目很容易陷入两个极端：
极端一：过度理想化
一开始就要求：
- 全厂设备一次性打通
- 所有设备都采全量参数
- 所有品牌统一标准
- 所有数据一次性对接到所有系统
结果往往是周期拉长、成本失控、现场推进困难。
极端二：过度简化
一开始只想着：
- 先买个网关
- 先读几个点
- 先做个看板
结果后面发现：
- 数据无法支撑业务
- 状态不准
- 周期算不对
- 不能接 MES
- AI 更无从谈起
更实用的做法是：
先围绕关键设备、关键数据、关键业务场景，做一套真正可用的采集闭环。
例如先明确：
- 先接哪些设备
- 先采哪些点
- 先解决什么问题
- 先交付给谁用
比如先做：
- 运行状态
- 产量
- 周期
- 报警
- 工单关联
把这条链路跑通，比一开始追求“大而全”更重要。
11. 从项目角度看，真正有价值的方案是什么
如果从交付角度总结，真正有价值的设备数据采集方案，不是“最炫”的方案，而是满足这几件事：
11.1 能稳定接入
设备能稳定读到，断网、重启、现场波动后还能恢复。
11.2 数据有业务意义
不是只采寄存器，而是能识别状态、周期、产量、异常。
11.3 能做边缘治理
不是把全部原始点位直接扔上去，而是能做：
- 变化上报
- 周期计算
- 状态归一
- 本地缓存
- 统计汇总
11.4 能对接上层系统
MES、看板、OEE、AI 平台能真正消费这些数据。
11.5 能扩展
后续新增设备、新增品牌、新增业务场景时，不需要推翻重来。
所以更准确地说：
工厂设备数据采集方案的本质，不是选某一个采集手段，而是设计一条从设备到业务系统的数据交付路径。
12. 结语
工厂设备数据采集并不存在一套万能模板。
协议直采、网关接入、OPC、IO 采集、外挂传感器、人工补录，各有各的边界，也各有各的适用场景。
真正合理的方案选择，应该基于：
- 设备开放性
- 业务目标
- 实施条件
- 扩展需求
对于制造企业来说，最值得警惕的不是“方案不够先进”，而是：
- 方案看起来很完整，但现场落不了地
- 数据看起来采上来了，但业务用不起来
- 系统做出来了，但后续无法扩展
所以，设备数据采集项目的重点从来不是“选一个最时髦的技术名词”，而是围绕现场实际条件，设计一套可接入、可治理、可交付、可扩展的数据链路。
广州聆机智能技术有限公司专注于工业设备数据采集、边缘数据治理与制造现场落地实施，适合需要从设备接入、网关部署、边缘计算到 MES / 看板 / AI 分析打通数据链路的制造企业。
