设备数据采集方案评估指南：19 项选型指标与判断标准

 

摘要：制造企业在评估数据采集方案时，最容易把注意力放在"这个设备能不能采上来"，而真正决定项目三年后还活不活得下去的，是另外四件事：异常情况下数据还剩多少、故障多久能发现和修复、需求变化时能不能不推倒重来、以及单台接入的综合成本是多少。本文按"采集完整性—稳定性可靠性—可运维性—演进能力—安全合规—TCO—集团推广"七个层次，拆出 19 个可打分的评估项，并给出每一项的判断标准和常见风险，供设备、工艺、IT 三方在选型和验收时逐条对照。

 

一、先说一个真实的失败样本

华南一家做汽车结构件的注塑厂，半年前上了一套设备数据采集系统。验收报告是合格的：MES 上看得到每台机的开合模次数、周期时间、报警代码。

问题出在运行第三个月。工艺部门发现稼动率曲线每隔几天就出现一段空白，短则十几分钟，长则两三个小时。供应商的判断是车间网络抖动；IT 查了接入交换机，端口没有 down 过；车间主任很确定机器一直在开。三方扯了一个多月，最后把网关拆回实验室，读存储才发现：日志把 4GB 的存储空间写满了，断网那段时间的数据一条都没缓存下来，网络恢复后也没有任何补传动作。

这套系统"能采到数据"，但扛不住一次普通的车间网络波动。

类似的情况在注塑、冲压、CNC 车间里反复出现，原因都差不多——采购阶段只验证了连通性，没有定义三件事：

1. 什么算"采到了"（是采到一次，还是按采集周期一条不落）；

2. 网络断了、停电了、设备重启了，数据怎么保；

3. 出问题之后谁修、多久能修、要不要供应商上门。

下面这 19 项，是我们在这几类场景里做方案评估时逐条过的清单。它不追求面面俱到，但每一项都对应一个已经发生过的坑。

 

二、把"采集成功率"这个词定义清楚

先纠正一个常见误解。"数据采上来了"和"数据完整"是两回事。

端到端的数据完整率可以粗略拆成三段相乘：

数据完整率 ≈ 采集成功率 × 链路可达率 × 平台写入率

举例：采集端 99%、网络链路 99%、平台写入 99%，看起来每个环节都很好，端到端只有约 97%。按单月 720 小时计算，97% 意味着每月有接近 21.6 小时的工艺参数、温度、压力数据是空白的。对于只做产量统计的场景，这可以接受；对于要做质量追溯、要拿数据应对客户审厂的场景，这 21.6 小时正好可能覆盖出问题的那一批。

所以评估方案时，不要问"支不支持这个协议"，要问"在网络中断、网关掉电、PLC 重启、平台升级这四种异常下，数据各保留多少，恢复多长时间"。

 

三、第一层：数据能不能采全（4 项）

1. 采集数据完整性

生产数据、设备运行状态、稼动率、产量、周期、运行参数、工艺参数、设定参数等等，方案要在不追加成本的前提下覆盖现有全部机型，并且留出后续接辅机（模温机、热流道、机械手、AOI等）、能耗、环境量的余地。

评估要点：让供应商按你现场的设备台账，逐台书面确认"原生驱动支持 / 需定制开发 / 不支持"，并注明是否额外收费。口头承诺不算。

2. 协议兼容性（南向）

这是第一优先级，因为现场品牌覆盖不全，直接结果是部分设备接不进来，或者每台设备都要单独付定制费。

至少要覆盖三类：

 

最后一行经常被漏掉。AOI 检测设备、三坐标、老式仪表往往没有通信接口，只能吐文件。如果网关不支持文件解析和数据库对接，这部分数据要么人工录入，要么再上一套系统。在方案阶段就要把"文件型数据"单独列出来问，别等到验收时才发现。

3. 设备适配方式

优先选择非侵入式采集：走网口或串口直读控制器数据，不改 PLC 梯形图、不破线、不加装影响原厂结构的传感器。

原因很实际：改动 PLC 程序有撞模和误动作风险，破线接入在部分行业会直接丧失原厂质保。对于没有通信口的老旧设备，可以要求旁路侦听方案（外接传感器或电表侧采集），而不是动控制器。

4. 数据点模型与可扩展性

点位能不能在线热配置——新增测点、修改采集周期、新增设备时，不需要停机重启网关，也不需要重新烧写固件。北向的数据模型是否统一，决定了后面接 MES 时是一次对接还是每台设备各接一次。

 

四、第二层：能不能一直采到（5 项）

这是本文的重点，也是大多数项目真正翻车的地方。

5. 网关硬件稳定性

车间环境对电子设备并不友好：粉尘、夏季机台附近 50℃ 以上的局部温度、变频器和伺服驱动的电磁干扰，再加上 24 小时不断电运行。商用级网关和用 Windows 工控机跑采集脚本的方案，在这里最容易出问题——死机、蓝屏、需要人工重启。

硬件层面要看的参数：

• 硬件级看门狗（WDT）：软件看门狗在进程卡死时同样失效，必须是硬件级；

• 宽温范围：标称 -20℃ ~ 70℃ 以上是工业现场的基本线；

• EMC 电磁兼容等级：要有明确的测试标准等级，而不是一句"工业级设计"；

• MTBF ≥ 10 万小时：约合 11.4 年，这是工业网关的常规门槛；

• 断电自恢复：来电后自动恢复采集，不需要现场人员按开关。

6. 网络架构合理性

这里的核心判断是单点故障半径。

• 集中式架构：一台工业 PC 采集全厂，宕机即全厂断采；

• 分布式架构：多台网关分区接入，单台故障只影响本产线，其余照常上传。

差距不只是"影响范围"，还有恢复难度。集中式架构一旦主采集机故障，恢复时间是小时级；分布式架构下换一台备件网关，是十分钟级。

配套要求：OT / IT 双网隔离（双网口或双网卡分别接设备网和办公网）、广播风暴抑制。

7. 数据传输稳定性

以 MQTT 为主的传输链路，要看这几个能力是否可配置：

• QoS 0 / 1 / 2 可选；

• TLS 加密传输；

• Keep Alive 心跳机制；

• 断线自动重连，且采用指数退避（避免网络恢复瞬间所有网关同时冲击服务器）；

• LWT 遗嘱消息（网关异常离线时，平台能立刻感知，而不是等超时）。

现场实践建议：QoS 1 + 应用层序列号去重。QoS 0 会丢消息，QoS 2 四次握手在弱网下开销偏大，QoS 1 配合应用层的序号校验和去重，是吞吐和可靠性之间比较均衡的选择。

8. 断点续传与本地缓存

这一项在质量追溯和审计合规场景里是硬指标——断网期间的工艺参数、温度、压力数据一旦丢失，是不可补的。

判断标准：

 

存储介质要特别问一句：不要选 TF 卡 / SD 卡。这类存储擦写次数有限，在持续写入日志和缓存的工况下，通常一年左右就会出现坏块。工业级 eMMC 或工业 SSD 是合理选择。

9. 时间同步精度

这一项最容易被忽略，但影响面很大。OEE 与稼动率统计、多机对比分析、停机原因追溯，全部依赖统一时基。跨网关如果存在几秒甚至几十秒的偏差，数据会在时间轴上错位，表现为"停机原因和实际停机时间对不上"，而且这种错误很难事后修正。

要求：支持 NTP 校时 + 本地 RTC 硬件时钟 + 毫秒级时间戳对齐。

 

五、第三层：坏了多久能发现、多久能修（2 项）

10. 可维护性（运行日志）

判断一套方案运维成本高低，最有效的办法是让供应商现场演示一次故障排查。

需要的能力：

• 运行日志分级（Debug / Info / Error），且级别可在线切换；

• 历史日志留存时长（建议 ≥ 30 天）；

• 报文抓包诊断能力：能抓到原始 Modbus 帧并导出，这是定位"到底是设备没回还是网关没发"的关键；

• 远程调试通道；

• 离线告警推送（网关自己掉线时，也要能发出告警）。

经验数据：一次现场上门排查的综合成本（人力 + 差旅 + 产线配合）通常是网关单价的 30%~50%。日志不完整时，同一个问题往往要多跑两趟。也就是说，可维护性上的差距，两三次故障就能抵消硬件价差。

11. 配置管理方式

• Web 网页配置，免装客户端软件（车间电脑上装专用配置工具，后期版本管理是灾难）；

• 支持批量配置下发（同型号设备一次配置几十台）；

• 配置可导出导入，方便备份和跨厂区复制。

 

六、第四层：需求变了，要不要推倒重来（4 项）

采集项目上线后 6~18 个月，一定会遇到扩容需求：加辅机、加能耗、改点位、换 MES。这一层决定的是第二次投入有多大。

12. 方案可扩展性

明确问一句：后续接入模温机、热流道、机械手、电表、水表，是否需要在网关侧追加硬件或授权？答案如果是"需要换型号"，那第一次投入里有一部分是沉没成本。

13. 二次开发能力

• 是否支持图形化编程（工作流式配置），让工艺工程师也能改逻辑；

• 是否支持通用编程语言（Python / JavaScript）；

• 脚本是否支持热加载（改完逻辑不用重启网关）；

• 对 AI 辅助编程的适配性——用主流语言写的脚本，工程师可以直接用大模型辅助生成和排错；用厂商私有脚本语言的，只能等厂商。

这项看起来是"开发者体验"，实际影响的是响应速度：现场一个采集逻辑的调整，是自己当天改完，还是提工单等两周。

14. 北向系统对接开放性

• MQTT / OPC UA / HTTP 多路并发输出，同一份数据可同时给 MES、看板、数据中台；

• 不绑定私有云；

• JSON 数据格式可自定义；

• 支持直写数据库。

这里有一个直接的判断方法：如果方案要求"必须用我们的平台才能看数据"，那么将来更换 MES 时，整套现场硬件大概率报废。数据出入口的开放性，本质上是换供应商的自由。

15. 边缘计算能力

纯透传网关会把全部原始数据上云，带来两个问题：带宽和服务器成本高；弱网下告警延迟大。

合理的做法是网关侧完成一部分计算：

• 本地数据清洗与过滤（死值、跳变剔除）；

• OEE 计算；

• 阈值报警规则引擎；

• 本地联动控制（如超温直接触发声光报警或停机信号，不依赖云端往返）。

 

七、第五层：网络安全（1 项）

16. 网络安全防护

注塑机、CNC 的控制器算力普遍较弱，网络防护能力接近于零。一旦暴露在办公网，容易被广播风暴拖垮，甚至感染病毒导致停机——这是真实的产线风险，不是理论风险。

要求：企业级 802.1X 认证、白名单机制、TLS 加密传输、网关自身具备防病毒与安全加固能力。

 

八、第六层：算 TCO，不要只比单价（2 项）

17. 成本与 TCO

把单台设备的接入成本拆开算：

单台综合成本 = 硬件摊销 + 协议驱动授权 + 实施工时 + 年度维护工时 + 扩容边际成本

举例：A 方案网关 3000 元/台，但每新增一类协议驱动收 5000 元授权费；B 方案 5000 元/台，协议全含。10 台设备、3 类协议的场景下，A 方案总价 30000 + 15000 = 45000 元，B 方案 50000 元——表面上 A 便宜，但第 11 台设备起，A 每新增一类协议仍要付费，B 不再增加。规模越大，B 越划算。

维护成本同理：需要人工现场重启的方案，和能远程恢复的方案，三年的运维投入不在一个量级。

18. 验证推广性

在集团有多个厂区的场景下，还要考虑：型号是否统一、配置模板是否可复用、固件是否能远程批量升级、故障处理经验能否跨厂复用。这些都直接影响第二个、第三个厂区的上线速度。

 

九、19 项评估清单（可直接打分使用）

建议在选型阶段组织设备、工艺、IT 三方各自打分，取平均分。任一单项低于 2 分的，要求供应商书面说明或写入合同补充条款。

评分标准：3 = 完全满足且有证据；2 = 基本满足；1 = 需定制开发或额外付费；0 = 不支持。

 

 

十、常见问题

Q1：工厂只有十几台设备，需要按这么复杂的标准评估吗？

规模小不代表风险小。断点续传、时间同步、远程运维这三项，在 10 台设备和 200 台设备上的必要性是一样的——区别只是投入方式。小厂建议的做法是：优先保证第 7 项（断点续传）、第 6 项（传输可靠性）和第 12 项（可维护性），这三项直接决定你会不会为了数据问题反复折腾。协议覆盖可以按现有设备从紧配置。

Q2：能不能不改 PLC 程序就采集？

大多数主流设备可以。注塑机的 Euromap 63/77 接口、CNC 的 FANUC FOCAS / 西门子 / 三菱 / 海德汉接口，都支持网口或串口直读，不需要改动控制程序。少数老型号设备没有通信口，可以走旁路方案（外接传感器、电表侧采集、或读取设备自带的文件输出）。真正需要改 PLC 程序的情况很少，如果供应商提出必须改梯形图，建议再找一家做方案对比。

Q3：MQTT 的 QoS 该选哪一档？

现场采集建议 QoS 1，配合应用层的消息序列号做去重。QoS 0 在网络波动时会直接丢消息；QoS 2 需要四次握手，在弱网和高点位频率下开销偏大，容易积压。同时必须配置 Keep Alive 心跳、指数退避重连和 LWT 遗嘱消息，否则平台无法及时感知网关离线。

Q4：断网期间的数据怎么办？

靠网关本地缓存 + 恢复后补传。关键是三个参数：缓存容量（≥ 8GB 工业级 eMMC）、容许断网时长（≥ 48 小时）、补传顺序（按时间戳顺序，不覆盖已有数据）。存储不要用 TF 卡或 SD 卡。验收时可以直接做测试：拔掉网线，运行一段时间，再插回去，看平台侧的数据是否连续、是否有重复或倒序。

Q5：能不能用工业 PC + 自己写脚本采集？

技术上可以，长期运行有问题。工业 PC 多为 Windows 系统，需要打补丁、会蓝屏、断电后不一定自动恢复采集进程；车间粉尘和高温环境下故障率明显高于无风扇嵌入式网关；多台 PC 的脚本版本管理、远程维护也是额外负担。适合做短期验证，不建议作为长期生产方案。

Q6：怎么避免被单一厂商锁定？

两个检查点：一是网关的数据出口是否开放（MQTT / OPC UA / HTTP 多路并发、JSON 格式可定义、可直写数据库），二是不强制绑定厂商私有云。做到这两点，更换 MES 或数据平台时，现场硬件可以保留。另外二次开发支持 Python / JavaScript 这类通用语言，比厂商私有脚本语言安全得多。

Q7：验收时最容易漏的是什么？

异常场景测试。大部分验收只测"正常联网状态下数据能不能上来"，没有测断网、掉电、PLC 重启、平台升级这四种情况。建议在合同里写明：四种异常场景下的数据保留要求、恢复时间要求，以及对应的验证方法。

 

十一、一个可执行的落地建议

不要一上来就全厂铺开。比较稳妥的节奏是：

1. 选一条产线做两周试点，覆盖现场最老的一台设备和最新的一台设备（这两台最容易暴露协议和适配问题）；

2. 用上面 19 项逐条打分，低于 2 分的项要求供应商给出书面说明或整改计划；

3. 做一次完整的异常演练：拔网线 4 小时、断网关电源一次、重启 PLC 一次，检查数据是否连续；

4. 把验收口径写进合同：数据完整率的计算方法、异常场景的处理要求、故障响应时限。

试点阶段花的这两周，基本可以避免后面两年的返工。