EAN-13 追溯：产线验收

目的与适用边界

让每个条码事件都走完判定送达和正确实物处置的全过程，包括读取失败（no-read）、结果迟到和应答缺失的情形。

本教程给出的是一套工程评估方法，而不是开箱即用的产品认证。Deyi Vision 目前公开的 PC 示例涵盖在已确认的样本图像上运行的 EAN-13 流程。工程代码中涉及原生 OCR 与检测的部分，使用前必须对照已安装的运行环境、已绑定的模型和作业逐项核对。浏览器模板并不能证明已在浏览器中实际运行：规划中的 OpenCV.js 后端需要单独验证。云端识别必须事先明确批准图像范围、服务提供方、模型和费用。评审存档不是可执行的发布包。相机、固件和驱动的兼容性需要各自单独核查。下列示例表中的所有数值均为假设数据，不是 Deyi Vision 的测量结果，也不是客户结果。

准备证据

冻结读码器范围、编码器约定、单件事件标识和已批准的商品映射。在有人监督的输送线运行之前，先测试处于禁止状态的输出。要定义以哪个时间戳作为截止时间的起点，以及哪个应答可证明已完成。排队延迟和通信延迟要与图像处理耗时一并保存，这样算法再快，也不会掩盖产线结果迟到的问题。时间间隔应使用单调计时；若各设备使用不同的时钟，还要另行用文档记录时钟之间的映射。不能只记录平均值，还要记录尾部延迟、结果缺失和重连行为。新配方不得重新解释已经在处理途中的结果；要么按已记录的版本处理完，要么执行约定的禁止流程。输出顺序、产品位置和确认信息要放在一起保存。验收记录应把分类正确，与通信成功、已确认的实物分流区分开来。解码、标识验证、印刷质量验证和单件跟踪应分别记录。EAN-13 值标识的是一种贸易项目，通常由多个实物单件共用；它既不是逐帧序号，也不是唯一序列号。解码成功，并不能证明印刷质量合规、商品主数据正确，也不能证明下游剔除成功。本系列以 EAN-13 作为限定范围的示例，因为这是已确认的公开 PC 评估范围。其他码制、QR 码、直接零件标记和读码器硬件，都需要各自经确认的集成。原始源图像必须保留条、空和静区；仅有裁剪后的显示图或清理过的二值图，不足以作为失败证据。要在追溯数据库中明确规定缺失的帧与无法读取的条码有何区别。把判定结果接到执行机构之前，先写好产线接口约定。定义采集标识、配方版本、结果状态、截止时间、应答，以及缺失或迟到数据的处置方式。先在输出被禁止的状态下演练握手，再按工厂验收流程做一次有人监督的产线试验。每次运行都从同一个已定义的事件开始计时；只看处理时间，会漏掉排队、传输和输出延迟。重复出现的产品标识符不是唯一的帧标识符。在仍有未完成任务的情况下，测试停止、重启、重连和配方切换。保留完整的序列，使被剔除的工件可以追溯到支持这一动作的证据。

步骤

1. 把采集位置对应到判定截止时间，并把约定的机械保护间隔明确写出来。
2. 发送事件 ID、解码内容或 no-read 原因，以及配方版本；对同一事件应答之后，才能关闭该事件。
3. 注入缺失帧、重复送达、结果迟到，以及在有单件待处理时重启；核实是否按约定进行了安全处理。
4. 将判定记录与编码器位置和有人监督下的实物路径进行比对；仅有应用层的接收回执，不等于剔除已得到确认。

解读试验结果

假设距离为 0.6 m，速度为 1.2 m/s，行程时间为 500 ms。80 ms 的判定预算和 40 ms 的保护间隔之后，还剩 380 ms。这只是预算示例，不是实测的读码速度，也不代表执行机构已就绪。编码器打滑、输送速度波动和队列延迟，必须在实际产线上测量。

记录表

travel = 0.6 / 1.2 = 0.5 s = 500 ms
margin = 500 - 80 - 40 = 380 ms

两个工程视角

故障排查

• 正确的解码内容如果关联到了下一个单件上，就属于一次追溯失败的结果。
• 只靠定时器、没有位置证据的剔除，在输送线减速时可能失效；要验证所声明的输送模型。

验收与交接

记录完整性、数据关联、截止时间符合性和实物处置，应分别验收。尚未解决的 no-read 和故障要保持可见；在声称具备投产条件之前，要留存有人见证的产线测试记录。

把源图像、预期判定、确切版本和完整的结果记录放在一起保存。在选定最终参数之前，先冻结评估集。如果之后用这些答案来调整工作流，就应把该集合标记为开发数据，并重新取得一个独立的验收集。Review、NoResult、执行错误和采集缺失都要保留在分母中，不得通过筛选行把它们变成合格。除成功样本外，还要保存一个可复现的失败样本。交接时应写明：谁可以更改配方，如何恢复先前已批准的版本，以及在验收之前哪些设备输出仍保持禁止。仅凭软件结果，不能证明移动中的实物工件已到达正确的目的地。