AI visual defect inspection (machine vision)

AI visual defect inspection replaces manual visual inspection with automated frame analysis from the production line. The system connects to existing QA-station cameras or is installed with new modules above the conveyor. Each part passes through the frame — a computer vision model classifies it as acceptable or defective, marks the defect coordinates, and sends a signal to the PLC, SCADA, or monitoring system.

What happens in practice

1. A fixed-angle camera captures each part at the inspection point on the line.
2. The preprocessing pipeline normalizes the frame: corrects exposure, angle, and scales to the model's resolution.
3. The computer vision model classifies the part: defect type, confidence, bounding box with coordinates.
4. The result is checked against the rubric: which defects are acceptable for the given batch, client, and specification.
5. On a defect, the system sends a signal to the PLC at the next station — mechanical rejection, marking, or line stop.
6. Metrics are written to the observability stack: shift, operator, batch, defect type, coordinates.
7. When the defect rate spikes above the control threshold, an alert is sent to the team messenger or ticketing system.
8. All images and verdicts are archived — they serve as an audit trail for customer claims and model retraining.

What the system does not do

• Does not replace final inspection of regulated products (medtech, aviation, high-risk food products). AI provides the initial signal; a person confirms the critical details and signs off.
• Does not detect defect types that were not present in the training dataset. New classes require retraining and new labeled examples to expand the dataset.
• Does not eliminate defect causes. The system catches the defect at the output, but root cause analysis remains with the process technologists and process engineering.

The system is built from four subsystems: image capture, model inference, decision-making, and production integration. Each subsystem is critical — a weak link nullifies the effect of the whole.

Technical pipeline

At the data level, everything starts with the camera. An industrial camera with the appropriate resolution is installed above the conveyor or on a robotic manipulator. Controlled lighting is provided for it: diffuse, coaxial, structured, or UV — the choice depends on the defect type. The frame trigger comes from a part position sensor or a line timer.

The captured frame goes to an edge inference server (a GPU machine near the line) or to a cloud endpoint, if the network is stable and the required latency is acceptable. The model consists of two heads: classification (pass / fail) and detection (defect localization with a bounding box). For each defect class, a labeled image dataset is collected and a convolutional neural network or vision transformer is trained.

The inference result is formalized in JSON: part ID, defect type, confidence, coordinates, timestamp. Next comes the rubric engine: rules for 'what defect level is acceptable' by batch, customer, and drawing revision. The verdict goes to the PLC via an industrial protocol (OPC UA, MQTT) and simultaneously to the observability stack, where dashboards are built for defect rates, false positives, and model drift.

Implementation steps

1. Line audit: where to install cameras, what lighting is needed, how many inspection points, what latency is acceptable.
2. Data collection and labeling: a labeled sample for each defect class, balancing of good and defective parts, rubric alignment with the QA department.
3. Baseline model training: transfer learning from a pretrained CV model, validation on a hold-out dataset.
4. Pilot on one line: parallel operation with manual inspection, collection of precision/recall metrics, threshold calibration.
5. Integration with PLC and MES: trigger subscription, verdict dispatch, automatic rejection.
6. Observability setup: dashboards, alerts for FP/FN growth, model drift metrics by shift, batch, and season.
7. Retraining policy: who labels new error cases, how frequently the model is updated, how to roll back to the previous version.

Typical components

The main source of errors is not the model, but the hardware. A glare, a camera shift of a millimeter, a change in the lighting film batch break the model faster than changes in the part. That is why drift monitoring is a mandatory module, not a nice-to-have.

Three groups of prerequisites are needed to launch: technology, data, team.

Technical side:

• An industrial camera with sufficient resolution and stable mounting above the inspection point.
• Controlled lighting suited to the defect type (diffuse, coaxial, structured).
• An edge server with GPU near the line, or a stable channel to a cloud endpoint with acceptable latency.
• Access to PLC or MES via an industrial protocol (OPC UA, MQTT) or REST for transmitting verdicts.
• Network connectivity between the camera, inference server, and monitoring system.

Data:

• A labeled image dataset for each defect class, with a balance of acceptable and defective samples.
• An agreed rubric: which defects are acceptable, which are not, and how this depends on the batch and customer.
• A sample of edge cases: rare defects and borderline instances that a manual inspection operator misses.

Team:

• A QA engineer responsible for the rubric and working in tandem with annotators.
• A process engineer who knows the line and can allocate windows for the pilot without stopping production.
• An IT/OT specialist for integration with PLC, MES, and observability.
• A data engineer or ML engineer for model training and support (in-house or contractor).

Timeline: mid-range scenario implementation — 6–10 weeks from audit to production operation on a single line. Scaling to adjacent lines takes a few weeks per line with similar geometry and lighting.