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、執行錯誤和取像缺失都要保留在分母中，不得透過篩選資料列把它們變成合格。除成功樣本外，還要儲存一個可重現的失敗樣本。交接時應寫明：誰可以更改配方，如何恢復先前已批准的版本，以及在驗收之前哪些裝置輸出仍保持禁止。僅憑軟體結果，不能證明移動中的實物工件已到達正確的目的地。