What it does
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 product passes through the frame — a computer vision model classifies it as good or defective, marks the defect coordinates, and sends a signal to the PLC, SCADA, or monitoring system.
What happens in practice
- A fixed-angle camera captures each product at the line's inspection point.
- The preprocessing pipeline normalizes the frame: corrects exposure, angle, and scales to the model's resolution.
- The computer vision model classifies the product: defect type, confidence, bounding box with coordinates.
- The result is checked against a rubric: which defects are acceptable for the given batch, customer, and specification.
- On a defect, the system sends a signal to the PLC at the next station — mechanical rejection, marking, line stop.
- Metrics are written to the observability stack: shift, operator, batch, defect type, coordinates.
- When the defect rate spikes above the control threshold, an alert is sent to the team messenger or ticketing system.
- 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 the causes of defects. The system catches defects at the output, but root cause analysis remains with process engineers and process engineering.
How it works
The system is built from four subsystems: image capture, model inference, decision-making, integration with production. 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 a suitable resolution is mounted above the conveyor or on a robotic manipulator. Controlled lighting is provided for it: diffuse, coaxial, structured, or UV — the choice depends on the type of defect. The frame trigger comes from a part position sensor or a line timer.
The captured frame is sent to an edge inference server (a GPU machine next to 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, client, and drawing revision. The verdict is sent to the PLC via an industrial protocol (OPC UA, MQTT) and simultaneously to the observability stack, where dashboards are built on defect rates, false positives, and model drift.
Implementation steps
- Line audit: where to install cameras, what lighting is needed, how many inspection points, what latency is acceptable.
- Data collection and labeling: a labeled sample for each defect class, balancing of good and defective parts, rubric alignment with the QA department.
- Baseline model training: transfer learning from a pre-trained CV model, validation on a hold-out set.
- Pilot on one line: parallel operation with manual inspection, collection of precision/recall metrics, threshold calibration.
- Integration with PLC and MES: trigger subscription, verdict delivery, automatic rejection.
- Observability setup: dashboards, alerts on FP/FN growth, model drift metrics by shift, batch, and season.
- Retraining protocol: who labels new error cases, how often the model is updated, how to roll back to the previous version.
Typical components
Layer | Components |
|---|---|
Hardware | Industrial camera, lighting, trigger sensor, GPU edge server |
Model | CV classification and detection model, anomaly detection, rubric engine |
Integration | Industrial protocol (OPC UA, MQTT) to PLC and MES |
Monitoring | Observability stack: dashboards, alerts, verdict and frame logging |
The primary 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.
Prerequisites
Three groups of prerequisites are required to launch: technology, data, team.
Technical section:
- An industrial camera with sufficient resolution and stable mounting above the inspection point.
- Controlled lighting matched to the defect type (diffuse, coaxial, structured).
- An edge server with a 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 verdict delivery.
- Network connectivity between the camera, inference server, and monitoring system.
Data:
- A labeled image dataset for each defect class, with a balance of good and defective samples.
- An agreed rubric: which defects are acceptable, which are not, and how this varies by batch and customer.
- A set 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 time windows for the pilot without halting production.
- An IT/OT specialist for integration with PLC, MES, and observability.
- A data engineer or ML engineer for model training and maintenance (in-house or contractor).
Timelines: implementation of a mid-range scenario — 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.
Pain points
- Compliance risks / legal errors
- Inconsistent Quality
- Errors in Manual Operations
FAQ
How long does implementation take?
A typical mid-complexity scenario takes 6–10 weeks. The first phase covers the line audit, camera and lighting selection. The next phase covers image collection and labeling, and base model training. The final phase is a pilot running in parallel with manual inspection, threshold calibration, and integration with the PLC and monitoring system. Scaling to adjacent lines goes faster and takes a few weeks per line.
What if we have no labeled defect images?
The most common scenario is no archive. Two paths. First: accumulate data in parallel with manual inspection, labeling photos as defects are found. Second: use anomaly-detection models that train only on good parts and flag everything that deviates. In practice both approaches are combined — anomaly detection for the pilot, then full classification as labeled data accumulates.
What are the risks and what can break?
Three main risks. First — drift from physics: a camera shift of a millimeter, a new batch of film on the lighting, morning-sun glare break the model faster than changes in the product. Second — false positives: aggressive thresholds raise FP, the line stops on good parts. Third — retraining without rollback: a new model version can degrade metrics if there is no canary deployment. We mitigate with drift dashboards and model versioning.
Is it suitable for our production?
Works in discrete and continuous manufacturing where defects are visible in the optical range: auto components, electronics, plastics, packaging, textiles, metalworking. Industry references — Bosch Jihlava (auto components, defect catch rate from 85% to 99–100%), Oxmaint (9 lines, 62 000 parts per day, miss rate reduction from 32% to 0.2%), Opsio (returns reduction from 3.2% to 0.4%). Not suitable where the defect is invisible to the eye — X-ray, ultrasound, or spectral analysis is required.
What about rare and new defect types?
Rare classes are the Achilles' heel of any CV model. Solved in two ways. First, anomaly-detection models that train only on good parts and flag anything unusual — even defects that were not in the training set. Second, a retraining protocol: any new missed defect goes to manual labeling and replenishes the training set with regular model updates.
Do we need to stop the line for the pilot?
No. The pilot runs in parallel with manual inspection on the working line: a camera is placed above the conveyor, AI verdicts are written to a log and compared with operator decisions. The line does not depend on the model until the calibration period is complete. Once precision/recall consistently stay above threshold values, the PLC connects to the AI verdict and manual inspection shifts to spot checks.
Want this in your business?
Book a free audit — we'll show how this automation will work for you.