4.5 Scanning, Databases & MES Links
Scanning and data integration are where physical marks become actionable traceability. Readers on the line capture every ID, while APIs stitch those scans into MES and ERP, creating a continuous thread from raw panel to shipped box. A minimal set of well-placed scan gates—panel-in, marking, depanel, test, and pack-out—ensures genealogy builds itself without slowing production. With a clean data model and guardrails against duplicates or mis-sequenced scans, every unit’s story is preserved in seconds, not spreadsheets. The result is a calm, predictable line and instant visibility when returns or audits strike.
4.5.1 Reader lineup (what lives where)
- Fixed-mount 2D imagers at stations that must never miss (panel ID in at SMT; unit SN after laser/label).
- Handheld 1D/2D for flexible spots (rework cells, debug benches, pack-out exceptions).
- In-process verifiers near printers/markers to grade freshly printed/lasered codes and block bad ones. All readers should speak the same symbologies you froze in 4.3 and write results straight into MES/ERP via API.
4.5.2 Where to scan in the route (minimal but sufficient)
Wire scan points into the MES route/operations/WIP states so the right code is required at the right moment.
- SMT panel in: scan panel barcode on the rails (stable, easy to hit) to start genealogy.
- After marking (laser/label): scan/verify unit 2D to bind SN ↔ panel/WO/BOM rev and write the record. (Ties to 4.2–4.4.)
- Depanel: scan panel ID then each unit SN to create the panel→units split record.
- Test (ICT/FCT): station reads SN at start, writes results at end (pass/fail, limits, firmware rev). Failures auto-open repair tickets.
- Final pack-out: scan unit SN → print/scan box label → post shipment record that links box↔unit(s). This “closes the loop” so a return can jump straight to its full build/test history.
4.5.3 Data model (the few tables that matter)
Keep it simple and relational; these keys unlock fast RMAs and clean audits.
Dashboards and alerts read from these same tables to watch early lots after changes.
4.5.4 API patterns (how stations talk to systems)
You don’t need a complex bus—just clear calls and webhooks:
- POST /scan {code, type, station, op, timestamp} → MES validates the op and advances WIP; rejects wrong codes.
- POST /test-result {sn, station, verdict, params} → logs to TestResult and (on FAIL) opens a repair ticket.
- GET /label-data?sn=… → returns customer-facing fields (SN, BOM rev, config) for box labels; ERP link adds ship-to/order info.
- Webhook: unit-ready → pack-out printers subscribe and print labels only for good units.
4.5.5 Guardrails (make bad data hard)
- Grade before accept: marking stations must verify code quality and block WIP on failure (your 4.4 gate).
- Duplicate & format checks: MES rejects reused SNs, wrong revs, or scans out of sequence based on the active operation.
- Store-and-forward: readers buffer when the network blips, then replay; no side spreadsheets.
- Operator feedback: short, colored station banners/alerts help leads react fast to scan/test spikes.
4.5.6 “Board to box” proof (what a clean record looks like)
Given an SN, you should pull in seconds:
- WO/line/shift, panel ID & depanel mapping, every scan event, ICT/FCT logs, rework/repair records, and box/shipment data—one story from the first rail scan to the shipping label. That’s the definition of closing the loop.
4.5.7 Release checklist (print this)
- Readers placed at panel-in, mark verify, depanel, ICT/FCT, pack-out.
- MES route/ops/WIP require the right scan at each step.
- APIs live: /scan, /test-result, /label-data; ERP link for shipments.
- Repair tickets auto-open on test fails; dashboards watch early lots.
- Panel rails reserved for codes; scanners can hit them fast.