Track & Trace links every individual part to its inspection and process data via a unique marking. Optical systems perform two tasks here: reliably reading the marking (DataMatrix, barcode, plain text) and assessing its quality. Marking method, contrast and the connection to higher-level data storage determine whether it works.
Why traceability is increasingly required
More and more end customers and regulations require proof that an individual part passed through manufacturing without defects. In automotive, medical technology and aerospace this has been standard for years, and other sectors are following. The benefit is twofold: in the event of a complaint, the affected scope can be narrowed down instead of blocking an entire batch. And process deviations become visible earlier, because inspection results can be analysed over time.
The three building blocks of optical traceability
- Marking: The part receives a unique identity – as a DataMatrix code (DMC), barcode, plain text or a combination.
- Reading and verification: A camera system reads the marking in-process and at the same time checks whether it remains permanently legible.
- Data linking: The identifier read is combined with inspection result, timestamp, station and, where applicable, process parameters and passed to an MES or database.
Marking methods and their optical properties
The choice of marking method largely determines how demanding the later reading will be. A code that is clearly visible to the human eye is not necessarily optimal for the camera – what matters is contrast under the chosen lighting.
| Method | Typical application | Optical characteristic |
|---|---|---|
| Laser marking | Metal, plastic, permanent | Contrast strongly material-dependent; on bare surfaces often only reliable in dark field |
| Dot peen (DPM) | Cast and forged parts, very robust | Pure geometry without colour contrast; requires directional lighting, frequently dark field |
| Label / print | Packaging, temporary marking | High contrast, easy to read; sensitive to abrasion, oil and temperature |
| Inkjet | High cycle rates, flexible content | Good contrast, edge sharpness varies with the substrate |
Reading is not the same as verifying
Two terms are frequently confused in practice. Reading means decoding the code content – it either succeeds or it does not. Verification additionally assesses the quality of the marking: contrast, cell uniformity, unused error correction and further parameters. Verification therefore detects that a code is deteriorating before it eventually becomes unreadable. Where customers contractually require a defined marking quality, verification rather than plain reading is the appropriate method.
Typical pitfalls in practice
- Varying part position: If the code location is not fixed, the field of view must be enlarged – which reduces the available resolution per code cell.
- Glossy and curved surfaces: Direct reflections can overexpose individual code cells. Diffuse or dark-field lighting is usually essential here.
- Contamination in-process: Oil, chips or coolant degrade contrast. The reading station should ideally be placed before such process steps.
- Cycle time: With moving parts, exposure time limits the achievable image sharpness – see our article on lighting and ambient light shielding.
- Data storage: Without a defined interface to MES or database, you get a reading but no traceability.
What to clarify before implementation
- Which data must be stored per part, and for how long?
- Is the code only read, or is a quality assessment of the marking required?
- At which stations is reading performed – once or several times in the process?
- How is data handed over to IT: directly to an MES, via the controller, as a file?
- What happens with an unreadable code – rejection, rework, manual entry?
These points belong in the requirements specification before hardware is selected. If an existing line is being upgraded, the conditions described in our article on retrofitting apply as well.
Have legibility tested on real parts before the marking method is fixed – not the other way round. A code read reliably on a sample part in the lab can fail under production conditions with oil, chips and varying part position. THOP AG tests reading under realistic conditions as part of a feasibility study.