MES车间数据采集有哪些方式：扫码、联网与人工报工对照

夜班交接时，班组交上来一沓报工纸单，白班文员照着往系统里敲。敲了几张发现其中两张的工序号写反了，还有一张没写设备号，只能打电话回车间问。等数据补齐，已经是隔天上午，计划员拿到的「实时产量」其实隔了整整一个班次。这类延迟不是系统慢，是采集方式没选对。昆山mes开发相关的话题里，采集往往被当成采购清单上的一项，实际它决定了后面所有报表能细到什么程度：是按分钟看设备状态，还是只能按班次看一个总数。

本文要点

• 采集方式按数据用途选，追溯用扫码、状态用联网，别全厂一刀切
• 报工单要有去重键与必填校验，事后补录必须打标记
• 联网前先出点位表，寄存器地址与采样周期写进方案再接线

采集方式概览

车间里能变成数据的动作，大致落在三个入口：人在终端上敲、扫一下码、设备自己上报。MES数据采集方式没有通用答案，同一条产线上混用两种甚至三种是常态。真正要先定的是「这条数据拿去干什么」——用于计薪和对外追溯的，准确性优先；用于设备状态看板的，实时性优先；只是补个备注的，成本低就行。

按入口分，人工报工靠工位终端、平板或纸单转录，产出的是一条结构化的报工记录；条码与 RFID 扫码靠载体带出上下文，产出的是「谁在哪个工单的哪道工序上做了什么」；设备联网靠 PLC、数控系统、电表或传感器上报，产出的是状态段与计数。三者的差别不在技术高低，而在数据是谁产生的：人产生的要防错，机器产生的要防丢。

还有一层容易被跳过：时间戳。三种方式都要统一到全厂 NTP，服务端记接收时间，终端记发生时间，两个字段都留着。断网补传时，靠发生时间还原顺序，靠接收时间判断数据新不新鲜。只留一个时间字段，后面算停机时长和跨班归属就会扯不清。搜昆山mes开发时如果只盯着界面和报表，这一层几乎不会被提到。

人工报工

人工报工不是落后方案，在很多换型频繁、单批数量小的工序上，它反而比装硬件划算。工位终端上放一个尽量少的界面：默认带出当前工单、当前工序、当前班次和操作工，人只需要填合格数、不良数与不良代码，起止时间由系统取服务端时钟。填的表单项越少，出错面越窄；让操作工自己选工单号，是错录的主要来源。

字段字典要先定。不良代码不能让人自由输入文本，否则「毛刺」「有毛刺」「边毛刺」会变成三个代码，月底按原因分组就散了。做法是给一张代码表，每个代码带所属工序与处置方式（返工、报废、让步），选完代码自动带出后续动作。数量也要加约束：合格数加不良数不得超过本道投入数，负数、超工单计划量、未开工就报完工，都在服务端挡住，别只靠前端提示。

补录规则得单独写清楚。常见情形是，终端故障或断网两小时，班组先记在纸上，恢复后由文员集中录入。这类记录要打「补录」标记，带原始发生时间、录入人、复核人，并且不能覆盖自动采集的同段数据。撤销用红冲追加一条负向记录，保留原记录可查。判断一套报工界面是否够用，看三件事：默认能带出多少字段、校验挡得住哪几类错、补录能不能一眼分辨出来。

• 默认带出：工单号、工序号、班次、操作工、设备号
• 人工只填：合格数、不良数、不良代码、备注
• 服务端校验：数量上限、状态前置、时间戳合理性、去重键
• 补录留痕：原始发生时间、录入人、复核人、补录标记

条码与扫码

车间扫码报工的核心不是枪，是载体上印了什么。流转卡或批次标签通常带料号、工单号、工序序列、批次号与流水号，用 Code 128 一维码、QR 码或 DataMatrix 码承载；金属件、高温件常改挂 RFID 或耐温标签。扫码那一刻，系统拿到工单号与工序号，再校验「上一道是否已报完工、本道是否已开工、这张卡是否已被扫过」，通过才写一条流转事件。这个校验是防呆的关键，少了它，跳工序、重复扫、拿错卡都会变成脏数据。

编码规则要覆盖批次变化。一批料拆成两批、两批合一批、返工后重新投线，编码都得能表达父子关系，不能简单在原号后面加个后缀了事。建议批次号里带日期、产线、流水三段，拆批时生成子批号并写一行父子映射，合批时记下来源批号清单。标签在哪几个点打印也要列出来：来料入库、投料、工序完工、成品入库，每个点的打印模板与粘贴位置固定，避免现场随手贴。

遇到过的一类情况是，扫码枪连扫两次，同一道工序写了两条完工记录，报工数比实物多出一批。除了前面说的去重键，还可以让终端在扫码后给一次明确回显（显示工单尾号与工序名），让人一眼看出扫的是哪张卡。硬件上，固定式扫描器适合流水线，手持 PDA 适合多工位走动；选型的判断标准是「操作工要不要多做一个动作」，需要额外绕一步的，漏扫率就会上来。

设备联网与协议

设备联网采集解决的是「不靠人也能知道机器在干什么」。常见路径是 PLC 或数控系统把信号放在寄存器或数据节点里，边缘网关按周期读取，再通过 MQTT topic 或 OPC UA 节点送到 MES。Modbus RTU / TCP 要写明从站地址、寄存器起始地址、数据类型与字节序；OPC UA 要写明命名空间与节点 ID；MQTT 要定 topic 层级、QoS 与心跳间隔。这几项不写进书面方案，现场接线时就会变成边试边猜。

点位表比协议选型更要紧。一张表逐行列出：信号名（运行、待机、故障、换型、加工计数、报警代码）、物理来源（哪个 PLC 的哪个地址）、数据类型、采样周期、上报条件（变化上报还是周期上报）、异常默认值。状态类信号建议变化上报，计数类按固定周期上报，报警类既变化上报又留一条带时间戳的事件。采样周期按用途定：算 OEE 的停机时长按秒级足够，做工艺参数曲线才需要更密，别把全部点位都设成同一个高频值。

老设备没有通信口是常态，不等于不能采。常见做法是在主轴或电机回路上加电流互感器判断开停，用接近开关或编码器取加工计数，再由一块小型网关汇总成状态段。这类「准联网」只能给状态和计数，给不了工艺参数，写方案时要如实标注数据能力边界。断网续传也要验：网关本地缓存若干小时，恢复后按发生时间补传，服务端按设备号加时间戳去重；NTP 不同步的话，补传数据和在线数据会互相覆盖。把昆山mes开发相关的讨论落到点位表这一层，才知道哪些数据是真能自动拿到的。

• 点位表字段：信号名、物理地址、数据类型、采样周期、上报条件、异常默认值
• 协议约定：Modbus 从站与寄存器地址 / OPC UA 节点 ID / MQTT topic 与 QoS
• 网关能力：本地缓存时长、补传顺序、去重键、心跳与离线判定
• 时间基准：全厂 NTP，终端发生时间与服务端接收时间各留一列

四类维度对照

把三种方式摆在同一张表上，选型的取舍会直观很多。下表按单工位改造投入、数据实时性、准确性、适用设备与主要失效点对照，数值只作相对比较，具体投入以现场勘测后的书面方案为准。

读这张表有个容易踩的坑：准确性一列里，联网写着「高」，前提是点位表对了。寄存器地址配错、字节序理解反了，系统会稳定地、成批地产生错误数据，比人工错录更难发现，因为它看起来很整齐。所以联网方案上线前要拿人工记录对账若干个班次，确认计数与状态段能对上，再撤掉人工那一套。成本一列也不只是硬件钱，标签耗材、点位维护、网关固件升级都要算进去。

判断标准可以归纳成一条：数据要用来做什么，就按那个用途反推采集方式。要回应客户追溯问询，扫码加批次映射就够；要算设备综合效率和稼动率口径，得有自动状态段；只是记录不良原因，人工选代码反而更快。反过来，先定「全线联网」再找用途，往往会出现一堆没人看的高频数据。

混合方案选择

现实里几乎没有全厂单一方式的方案，混合才是常态。分层的依据仍是数据用途：瓶颈设备与连续产线走联网，拿状态段和计数；离散装配与批次流转走扫码，拿工序事件和追溯链；异常、不良原因、备注这类需要人判断的信息，留给人工补录。三类数据共用同一套工单号、设备号、班次代码，落到同一张事实表里，报表才不会各算各的。

推进顺序建议按「先软后硬」。先把主数据编码、字段字典、去重规则、补录标记这些不花钱的部分定下来，再做点位勘测和网络勘测，然后选一条产线接网关与扫码器，跑完整一轮闭环后评估，到收尾阶段才谈扩展。顺序反过来，硬件装好了却发现工单号在两边编码不一致，返工量会集中在代价偏高的一段。昆山mes开发相关讨论常忽略这一段，其实它决定了项目里哪些钱是必须花的。

验收别只看「界面上有数了」。可以按下面几条逐项核，任何一条不过，都先补再扩：

• 拿一张真实工单，扫码记录与报工记录能对上同一道工序
• 设备计数与人工点数对账若干个班次，差异能解释清楚
• 断网一段时间后恢复，缓存数据补传且不重复
• 补录记录带标记，能被单独筛出来
• 跨班工单的时间戳连续，状态段首尾接得上

更多同主题的技术拆解放在行业动态栏目，涉及具体点位勘测与书面方案范围，可到免费咨询沟通一般性问题。把采集方式选定，后面的 OEE 口径、批次追溯才有可用的底稿。

小结

采集方式没有高低之分，只有匹配与否：人工报工要防错，车间扫码报工要防漏，设备联网采集要防丢和防点位错。四条维度对照下来，取舍其实落在「这条数据拿去干什么」上。明天就能做的一件事：挑一台机列出它的点位表草稿，把信号名、物理来源、采样周期、上报条件四列先填上，空着的格子就是勘测时要问的问题。同簇整理可先翻行业动态栏目。本文为行业经验与技术分享，不构成效果承诺；具体交付范围、周期与资费以书面方案为准。