Machine Vision Traceability: Images, Results, Recipes, and MES
Design a trustworthy inspection record that links the correct part, image, result, recipe, calibration, timestamp, and production context.
A customer disputes a rejected lot, but the stored image cannot be linked confidently to the part because IDs were assigned after inspection and recipe versions were overwritten.
This article presents a vendor-neutral engineering method. Worked figures are hypothetical and must be replaced by evidence from the actual line.
What you will learn
Understand the physical and data-processing limits behind machine vision traceability and mes.
Translate an inspection need into measurable component and system requirements.
Calculate or test the variable that most strongly controls reliability.
Recognize common integration mistakes before commissioning.
Validate the final method under representative production conditions.
Technical foundation
Identity must be deterministic
Part ID, carrier position, trigger, and image sequence must stay associated through queues, rework, and retries.
Context makes a result reproducible
Recipe, model, thresholds, software, camera settings, calibration, and source versions explain how the decision was produced.
Retention is risk-based
Storing every raw image may be valuable but expensive. Policies should distinguish metadata, thumbnails, rejects, audit samples, and regulated records.
[Suggested visual: traceability chain linking part token, trigger, image, result, recipe, calibration, and MES record]
Purpose: Clarify the physical or architectural mechanism before component selection.
Required elements: Use labelled rays, axes, signals, components, and the failure mode described; keep scale relationships physically plausible.
Suggested caption: “Traceability chain linking part token, trigger, image, result, recipe, calibration, and MES record.”
Accessible alt text: “Technical diagram of traceability chain linking part token, trigger, image, result, recipe, calibration, and MES record.”
Engineering workflow
1. Define the traceability question
What to evaluate: recall, root cause, customer evidence, model improvement, and compliance.
Why it matters: data design follows intended use.
How to measure or calculate it: write retrieval scenarios and required response time. Record the input conditions and keep the same method when comparing alternatives.
Trade-off: more evidence increases storage and governance. What commonly goes wrong: saving data without a retrieval purpose.
2. Anchor part identity
What to evaluate: serialization point, trigger, PLC token, carrier, and retry rules.
Why it matters: late or ambiguous identity corrupts the record.
How to measure or calculate it: simulate queues, gaps, and rework. Record the input conditions and keep the same method when comparing alternatives.
Trade-off: physical marking may occur after inspection. What commonly goes wrong: joining only by timestamp.
3. Design the result schema
What to evaluate: part ID, station, timestamp, decision, scores, defect classes, measurements, and validity.
Why it matters: structured fields support analysis and interoperability.
How to measure or calculate it: version the schema and define units. Record the input conditions and keep the same method when comparing alternatives.
Trade-off: rich schemas require lifecycle management. What commonly goes wrong: putting all results in one opaque text field.
4. Capture configuration lineage
What to evaluate: recipe ID, immutable version, model hash, calibration ID, camera settings, and software build.
Why it matters: overwritten recipes destroy reproducibility.
How to measure or calculate it: store references that cannot be silently reused. Record the input conditions and keep the same method when comparing alternatives.
Trade-off: immutability consumes storage and process discipline. What commonly goes wrong: saving only recipe name.
5. Choose image retention
What to evaluate: raw/processed images, compression, trigger conditions, sampling, and duration.
Why it matters: retention must balance evidence, privacy, network, and cost.
How to measure or calculate it: calculate worst-case data rate and retrieval tests. Record the input conditions and keep the same method when comparing alternatives.
Trade-off: lossy compression may alter defect evidence. What commonly goes wrong: keeping every image forever by default.
6. Integrate safely
What to evaluate: PLC real-time path, MES transaction, buffer, retry, and offline operation.
Why it matters: quality decisions must not depend on a fragile database round trip.
How to measure or calculate it: test store-and-forward and idempotent writes. Record the input conditions and keep the same method when comparing alternatives.
Trade-off: local buffering needs capacity and reconciliation. What commonly goes wrong: blocking the inspection cycle on MES response.
Worked example
Hypothetical storage plan: 2 MB compressed image, 1 part/s, 24 h/day.
Daily raw volume = 2 MB × 86,400 = 172,800 MB ≈ 173 GB/day
30-day volume ≈ 5.18 TB before replication and indexes
A tiered policy—metadata for all parts, images for rejects, and a sampled set of accepts—may be more sustainable if business and regulatory needs allow it.
[Suggested visual: tiered image-retention architecture with capacity calculation]
Purpose: Turn the engineering workflow into a resource that can be used during commissioning and review.
Required elements: Include the inputs, decision points, measurable outputs, acceptance boundary, and major failure branches.
Suggested caption: “Tiered image-retention architecture with capacity calculation.”
Accessible alt text: “Technical diagram of tiered image-retention architecture with capacity calculation.”
Practical decision aid
| Record element | Why retain it | Common failure |
|---|---|---|
| Part/lot ID | product linkage | timestamp-only join |
| Result and validity | quality decision | invalid frames recorded as pass |
| Recipe/model version | reproducibility | mutable recipe name |
| Calibration/settings | measurement context | missing configuration |
| Image reference | visual evidence | orphaned file path |
| Interface transaction ID | deduplication | duplicate MES writes |
Use this table to choose the next experiment, not as a universal component recommendation. Record actual settings, part variants, and evidence beside the decision.
Common mistakes and how to prevent them
Joining only by timestamps. Queues create wrong matches. Prevent it by use explicit tokens.
Overwriting recipes. Past results cannot be reproduced. Prevent it by use immutable versions.
Storing images without metadata. Files are orphaned. Prevent it by write atomic records.
Blocking on MES. Network outage stops inspection. Prevent it by buffer locally.
No retention calculation. Storage fills unexpectedly. Prevent it by model worst-case volume.
No invalid-result state. Faulty acquisitions appear as quality results. Prevent it by separate validity from pass/fail.
Validate under production conditions
Run identity gaps, duplicate triggers, rework loops, network outages, database slowdown, full disk, clock changes, recipe updates, and retrieval audits. Verify no lost or duplicated records, bounded buffering, reconciliation, and reproducible decisions.
A defensible validation set includes representative acceptable parts, defective parts, boundary cases, and nuisance variation. Repeat complete part presentations rather than processing one stored image many times. Include environmental extremes, line-speed limits, start-up and warm-up, maintenance states, interface faults, and long-duration operation where relevant.
Predefine acceptance criteria for false accepts, false rejects, invalid acquisitions, repeatability, cycle time, and recovery. Preserve raw counts and denominators. After release, trend leading indicators and audit labelled samples so that drift is detected before it becomes a customer escape.
Key takeaways
Traceability begins with explicit part identity.
Store immutable configuration lineage.
Separate acquisition validity from quality result.
Size retention before production.
Use buffered, idempotent factory integration.
Follow this Hashnode blog for more practical industrial machine-vision engineering, and connect with Kivanc Ekici on LinkedIn. For related machine-vision and automation information, visit ITAGE.
Frequently asked questions
Should every inspection image be stored?
Only when justified by risk, regulation, analysis, and cost; tiered retention is common.
Why is recipe name insufficient?
Names can be reused or edited; an immutable version or content hash is needed.
Can timestamps link images to parts?
They help, but explicit transaction or carrier tokens are safer under queues and retries.
What happens during an MES outage?
The station should follow a defined local buffer, retry, and reconciliation policy.
How can OPC UA help?
The Machine Vision companion specification provides a vendor-neutral information model for states, recipes, and results.