OCR 标签核对：验收与 PLC 约定

目的与适用边界

按字段给出判定结果，同时带有可追溯的文本和时限，并在产线上把错误文本、不可读文本和通信故障区分开。

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

准备证据

冻结字段定义、批号来源标识、规范化规则和 OCR 包。先从模拟的输出约定入手，再使用有人监督的真实标签。要明确规定哪个时间戳作为时限的起点，以及哪个应答可证明已完成。把排队和通信延迟与图像处理时间一起保存，这样算法再快，也不会掩盖产线结果迟到的事实。时间间隔用单调时钟计时；各设备时钟不同时，另行记录时钟映射关系。要记录尾部延迟、缺失结果和重连时的表现，而不能只记平均值。新配方不得重新解释已在处理中的结果；要么按记录的版本处理完，要么执行约定的禁止流程。输出序列、产品位置和确认信息要放在一起保存。验收记录应把分类正确、通信成功和实物流向已被确认区分开。OCR 标签核对是一项数据完整性任务，而不是在找看似合理的词。定义每个字段、字段位置、预期字符集、精确比对规则，以及预期值的可信来源。批号字段、日期字段和产品名称可能需要不同的规则。在规范化空格或大小写之前，先保留文字检测多边形和识别器的输出。不要悄悄地把 I 替换成 1，或把 O 替换成 0：这会让错误的标签看起来正确。原始工程证据中有一个窄条形的 OCR 边界案例，其结果为 NoResult 或 Review；增大裁剪范围并不能证明识别已普遍可用。可读的字段仍可能是错误的批号；而预期值本身正确，也不能成为把它填进不可读字段的理由。在把判定结果接到执行机构之前，先写好产线约定。定义采集标识、配方版本、结果状态、时限、应答，以及数据缺失或迟到时的处置。先在输出被禁止的状态下演练握手，再按工厂的验收规程进行有人监督的产线试验。每次运行都从同一个已定义的事件开始计时；只看处理时间，会漏掉排队、传输和输出延迟。重复出现的产品标识符不是唯一的帧标识符。在有未完成工作的情况下，测试停止、重启、重连和配方变更。保留完整的序列，使被剔除的工件能追溯到作为该动作依据的证据。

操作步骤

1. 在汇总出标签判定之前，先把每个字段的结果定义为精确匹配、不匹配、Review、NoResult 或执行错误之一。
2. 随判定一并发送采集 ID、版本和原因；不要让迟到的匹配结果去替换已超时的标签。
3. 在有任务待处理时，注入字段缺失、批号错误、运行环境缺失和重启等故障；检查约定的禁止输出路径。
4. 把时限预算与观测到的从采集到应答的间隔作对比，然后核实标签的实物处置。

解读试验

在假设的预算中，OCR 用时 55 ms，规则判定 5 ms，通信 5 ms，合计 65 ms，而时限为 80 ms，余量 15 ms。这不是实测的 OCR 速度。即使文本正确，超过时限的结果仍然算迟到。

记录表

T = 55 + 5 + 5 = 65 ms
M = 80 - 65 = 15 ms

两种工程视角

故障诊断

• 只有整体合格标志、没有逐个字段结果，可能会掩盖不可读的日期或批号。
• 对应另一次采集的回执，不得用来应答当前标签。

验收与交接

字段完整性、数据精确无误、故障处理和产线应答要分别验收。记录实际验收所用的硬件和已安装模型的标识。

将源图像、预期判定、确切版本和完整的结果记录放在一起保存。在选定最终参数之前，先冻结评估集。如果这些答案之后被用来调整工作流，就要把该集合标记为开发数据，并另取一套独立的验收集。Review、NoResult、执行错误和缺失的采集都要保留在分母中；不要通过过滤数据行把它们变成合格。可复现的失败案例要与成功样品一并保存。交接内容应写明：谁可以修改配方，如何恢复先前获批的版本，以及在验收之前哪些设备输出保持禁止。仅凭软件结果，并不能证明运动中的实物工件到达了正确的去向。