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、執行錯誤和缺漏的取像都要保留在分母中；不要透過篩掉資料列把它們變成合格。可重現的失敗案例要與成功樣品一併保存。交接內容應寫明：誰可以修改配方，如何還原先前獲核准的版本，以及在驗收之前哪些設備輸出保持禁止。僅憑軟體結果，並不能證明移動中的實體工件到達了正確的去向。