企业官网建设流程全解析

读码器读得出来，屏幕上也有码，但 MES 里就是查不到这件产品。这是产线数字化改造里常见的一类问题，也容易被误判：现场工程师往往一头扎进读码器的参数里调，调了两天发现读码器一点问题没有，卡的是数据出不去，或者出去了但对方不认。接不上不是一个问题，是三层不同的问题，判别方法和修法都不一样。先分清卡在哪一层，再动手。

一、先把「接不上」拆成三层

判别只用一个动作：先数记录条数。一条都没有，是通信层；有但对不上，是数据层；对得上但查不出来，是追溯层。这三层的修法完全不重叠，混着修是费时间的走法。

有一个反直觉的地方要说清楚：三层里贵的不是通信层，是追溯层。通信层的问题多数能在半天内定位，追溯层的问题往往要改数据模型，属于上线前不定、上线后难改的那一类。

二、通信层：读码器读到了，MES 没收到

通信层先要理清一件事：读码器在架构里的位置。多数产线并不是读码器直接连 MES，而是读码器把结果交给 PLC，PLC 再往上给 MES。读码器直连 MES 是并行的一条路，走不走取决于 MES 侧愿不愿意开设备接入。

这张表里容易被误用的是一行。OPC UA 不是「更高级的现场总线」，它是跑在 TCP/IP 之上的应用层协议，作用是让数据带着语义和身份往上走。把它放到读码器与 PLC 之间去做触发和实时控制，是放错了层。合理的分工是：现场层走 Profinet 或 Modbus，控制层往上用 OPC UA 交给 MES。

协议定了，还有五件事要一一对齐，这五件事没对齐，协议对了也解析不出来：

• 编码：ASCII 还是十六进制。同一串码，两种编码发出去，对方收到的字节完全不同。
• 结束符：回车、换行，还是两者都要。没有约定结束符，接收端只能按超时切帧，超时设长了会粘包，设短了会截断。
• 字节序：多字节数据是大端还是小端。码本身不受影响，但同一报文里的长度、计数字段会。
• 前后缀：要不要加站号、要不要加状态位。加了对方不认，不加事后分不清数据来自哪台设备。
• 码内容本身：大小写是否统一、首尾空格是否去掉、有没有不可见字符。这一条琐碎，也容易在联调时耗掉半天。

现场排查通信层，按灯、包、格式三步走。先看通信状态，确认链路在；再抓一次包或读一次对方寄存器，确认数据真的发出去了；第三步核对上面五件事，确认对方能解析。跳过抓包直接改配置，是常见的无效劳动。

还有一条现场经验值得单独提：TCP 客户端模式下，断线后不一定自动重连。产线网络抖动一次，读码器可能还认为自己连着，实际上一整天没再发出去一条。心跳检测和重连间隔要在联调阶段就配好并测过，不能等上线后靠人发现。

三、数据层：记录有了，账对不上

数据层的症状是记录条数不对。四种病，成因和修法都不同。

四种病里，缺记录和重复记录容易被当成读码问题去查，实际多数不是。读码器本地有记录、MES 没有，是上传环节的事；同一件读了两三次，是触发和锁存的事。判别的入口很明确：把读码器本地日志和 MES 记录按时间并排比，差在哪一步一眼能看出来。

一个架构上的原则值得写进设计文档：接收和上传要解耦。收码的线程只管把字节流按结束符切干净、放进本地队列；上传是另一个线程，从队列里取、批量发、失败回队。把 HTTP 请求写在收码回调里，网络一慢收码就跟着堵，堵到触发信号都接不住，丢的是整段产线的数据。

四、追溯层：记录是全的，反查还是查不出来

这一层容易被忽略，因为它不出错，只是没用。记录条数对得上，随机抽一个序列号去查，查不到它在哪个工位、当时用的什么参数、属于哪个批次。这就是追溯不成立。

追溯要成立，得有三个绑定关系，缺一个就断链。

三个绑定里，站号共用是较隐蔽的一种。一条线上装了几台读码器，如果都用一个默认站号，事后看数据完全分不清是哪台读的，来源信息等于没有。这件事在安装阶段按工位编号分配、写进台账，成本几乎为零，事后补要停产排查。

再往前一步是追溯粒度，这个在上线前就得定，定完才好定字段。

批次级追溯是每个批次一个标识，记录这批的原料、设备、人员和参数。成本低，圈定范围时是一整批。单件级追溯是每件一个唯一码，记录这一件的完整履历。成本高，但问题件能精确定位到个体。混合做法在实际项目里常见：关键件按单件级管，非关键件按批次级管，两者通过绑定关系连起来。

不同行业的合规要求不一样，选粒度不能凭感觉：汽车行业相关体系一般要求批次级，涉及安全的件要求到单件；医药行业要求单件级；食品行业常见的要求是向前一步、向后一步。客户审核时看的是能不能拿一个成品码反查到它的全部履历，只做到批次级的系统在这类审核里过不去。

方向上有两条路要都能走通。正向是从某个批次或原料出发，查它流到了哪些成品，召回时用；反向是从一个成品码出发，反查它的工序、参数和物料批次，客诉分析时用。两条路的数据基础是同一个：码与物料批次的绑定关系在投料或上料那一刻就建立起来。这个绑定漏了，反向追溯就断在源头。

五、落地顺序：从追溯粒度往回定，不要从设备往前推

这一类项目常见的返工，是先买了设备、装好了、再去问 MES 要什么格式，结果发现字段不够、站号没规划、时间戳来源不一致，回头改。

这个顺序倒过来做，前面省的时间后面要成倍还回去。字段这一层尤其如此：MES 侧的接口表和数据库字段，改一次要动开发，比读码器改配置贵得多。

六、验收：五项试验，别等上线才发现

联调做完不等于通了。五件事各做一遍，通过了才算站住。

这五项里，断网试验和反查试验容易被跳过，也容易在上线后暴雷。断网试验验的是缓存与重发，反查试验验的是绑定关系，这两个恰好是事后难补的。

读码器读到码只是起点。数据能从设备走到 MES，才算通信通了；条数对得上、不重不漏不乱，才算数据对了；拿一个码反查出它的履历，才算追溯成立。三层各有各的判据，混着查只会越查越乱。按数条数、对账、反查的顺序走，多数问题在半小时内能落到具体一层。