Computer Vision in Manufacturing: Quality Control, Safety Monitoring and Why MES Integration Decides the Outcome

Computer vision is the easiest thing in a smart factory to demonstrate and one of the harder things to put into production. A model that spots a defect in a slide deck is a solved problem. A model that holds up on a line at 3am, in November, when the sun no longer comes through the roof light the way it did during the pilot, is a different exercise.

This is what separates the two, and what to ask a vendor before the proof of concept rather than after.

What vision is genuinely better at than a person

Consistency at speed, on a defined defect, forever. A human inspector is better than any model at noticing something new and strange. A human inspector is worse than any model at looking at the eight-hundredth part of a shift with the same attention as the first.

So the cases that pay back share a shape: high volume, a defect class you can describe, and a cost of escape that is real. Surface defects on a moving web. Presence and orientation of components before a case is sealed. Label, lot code and date legibility — dull work, and one of the most common causes of a customer complaint in food and pharmaceuticals. Fill level and seal integrity. Dimensional checks that a person does with a gauge and a clipboard.

The cases that disappoint share a shape too: rare defects with no image history, defect definitions that change with the customer’s mood, and anything where the honest answer is that two experienced people disagree about whether it is a defect.

Real-time safety monitoring is a different product

Safety monitoring gets bundled with quality vision and behaves nothing like it. Quality inspection looks at a part in a controlled frame. Safety monitoring watches an area for people, PPE compliance, forklift and pedestrian proximity, and access to a zone that should be empty while a machine is cycling.

The technical difference is that safety runs continuously on an uncontrolled scene, so false positives are the whole problem. A quality model that cries wolf produces rework. A safety model that cries wolf gets muted within a fortnight, at which point the system is worse than nothing because it is now trusted and wrong.

The organisational difference is bigger. Recording people at work is a works-council and data-protection question in most of Europe before it is a technical one. The deployments that survive are the ones that agreed retention, anonymisation and who may view footage before a camera was mounted, not after.

Why integration decides whether it is a system or a demo

A vision cell that lights a red lamp has told the operator standing there. That is all. It has not told the plant.

What makes inspection compound is the write-back. The verdict lands against a work order, a batch, a station and a timestamp, in the same system that holds the rest of production. Once it does, several things become possible that a standalone camera cannot do at any accuracy.

A failure blocks the next operation automatically, so the part does not accumulate value on its way to being scrapped. Defect rate becomes a variable that scheduling can see, so a machine drifting out of tolerance changes the plan instead of surprising it. Genealogy answers a recall question in minutes, because every image and verdict is tied to a batch that is tied to a supplier lot. And the model gets better, because operator overrides become labelled training data by construction rather than by someone remembering to export a folder.

This is why the integration question belongs before the accuracy question. Ask which system holds the work order the verdict is written against. If the vision platform keeps its own separate production record, someone will be reconciling two versions of the truth.

What a deployment actually needs

Lighting, first and least glamorously. Most vision projects that fail on accuracy failed on illumination and repeatability of presentation, not on the model. Controlled, consistent lighting and a fixed part position beat a better algorithm almost every time.

Images of the defect, second. A few hundred labelled examples per defect class is a realistic starting point for most surface and presence tasks. If a defect happens twice a year, vision is not the tool — that is a process-control problem.

A decision about what happens on a positive, third, made before go-live: reject, hold, alarm, or flag for review. Teams that leave this to be decided later end up with an inspection system nobody is authorised to act on.

And an override path for operators, fourth. Not as a concession — as the mechanism that makes the model improve and the thing that keeps trust intact the first time it is wrong.

Edge or cloud

Inference belongs at the edge, next to the line. Latency and network dependence are not acceptable risks for a decision that has to happen between two stations, and a plant should not stop inspecting because a WAN link flapped.

Training, model management, versioning and cross-plant comparison belong centrally. A group running the same product in four countries wants one model lineage, not four locally tuned models that quietly diverge until their scrap rates are no longer comparable.

How to run the proof of concept so it proves something

Pick one defect class, on one line, with a cost attached. Run it in parallel with existing inspection rather than instead of it, and count disagreements in both directions — misses matter more than false alarms, and only the parallel run exposes them.

Run it across a shift pattern and, if possible, across a weather change. Set the pass criterion before starting and in the plant’s own terms: escapes per thousand, or inspection labour hours released. A proof of concept without a pre-agreed threshold always ends in an argument about whether ninety-four percent is good.