What are Computer Vision & Edge AI Systems?

What does a typical computer vision and edge AI stack look like?

A typical stack is a loop with five stations: cameras and optics, an edge inference runtime, line-system integration, an operator review layer, and a cloud training pipeline that ships improved models back to the edge. Vision runs on the line, learning runs in the cloud, and operator corrections connect the two.

• Cameras and optics — Industrial cameras with engineered lighting. Half the accuracy of an inspection system is decided here, before any model runs — glare, vibration, and dust degrade capture quality daily, and they are lighting-and-mounting problems, not modelling problems.
• Edge inference runtime — A model trained in PyTorch, exported to ONNX, optimised with TensorRT, and served on an NVIDIA Jetson-class device or GPU-equipped industrial PC. Quantisation and pruning trade a point of accuracy for the milliseconds the cycle budget demands.
• Line integration — Verdicts become actions through PLC signals and MQTT messages: reject the part, alert the operator, log the result. An inspection verdict that reaches no actuator and no workflow is a demo, not a system.
• Operator review and labelling — A dashboard where operators confirm, override, and correct verdicts in one tap. Every correction is a labelled training example — the cheapest, most valuable data the programme will ever collect.
• Cloud training loop — Curated images and corrections retrain the model on cloud GPUs; new versions are validated against a held-back benchmark and rolled out to the edge fleet as signed updates.

Operating that loop across a fleet of devices — versioning, monitoring, staged rollouts, drift detection — is a discipline in its own right; our MLOps cloud engineering primer covers it. The edge constraint changes the tooling but not the principle: a model nobody monitors is a model quietly getting worse.

How do you size the edge hardware?

Size the device from the frame budget, not from the model: count the frames per second the line actually produces, decide the resolution the smallest defect needs, and pick the cheapest module that clears the cycle deadline with headroom left for a larger model next year. Choosing hardware before measuring those three numbers is how programmes end up with an expensive module that still misses the deadline.

The arithmetic is blunt and worth doing on paper first. A line at one part per second with two cameras leaves roughly 500 milliseconds per frame, minus capture, transfer, and the PLC handshake — call it 300 milliseconds of real inference budget. A line at four parts per second leaves 125 milliseconds gross — a different device, a different model size, often a different lens. Halving cycle time does not halve the hardware bill; it changes the design.

Compilation buys back most of the difference. A PyTorch model exported to ONNX, compiled with TensorRT, and quantised to INT8 runs materially faster on the same silicon, at a cost of a fraction of a point of accuracy. The only benchmark that counts is accuracy and latency measured together on the target device — a model validated on a workstation GPU has proved nothing about the line.

Then there is the enclosure. Floor deployments are fanless, ruggedised, and sealed against dust and coolant mist, which caps the thermal budget well below the module's headline rating. Specify mounting, ingress protection, and power envelope with the maintenance team when you choose the module, not after the pilot has proved the model.

How do you deploy a computer vision system on a production line?

A production deployment starts with a single line and a small set of defect classes, and reaches a running pilot in 8–12 weeks. The order is fixed even when the details vary — engineer the capture first, model second, integrate third — and every step is judged against three numbers agreed in advance: catch rate, false-alarm rate, and cycle-time impact.

1. Scope one line and engineer the capture (weeks 1–3)

   Pick one line and two or three defect classes with measurable cost. Install cameras, optics, and lighting with the line engineers, and prove capture quality across shifts — lighting changes and vibration break more vision projects than model choice does.

2. Build the defect dataset (weeks 2–6)

   Collect images across products, shifts, and conditions, and label them with the quality engineers who own the defect taxonomy. Rare defects are scarce by definition — seeded defects and augmentation fill the gap while real examples accumulate.

3. Train, then optimise for the cycle budget (weeks 4–8)

   Train detection models on the labelled set, then compile for the edge target — ONNX export, TensorRT optimisation, quantisation — until inference fits the milliseconds the line allows. Benchmark accuracy and latency together: a model that is accurate but late is wrong.

4. Shadow-run and tune false alarms (weeks 6–10)

   Run alongside existing inspection without acting on verdicts. Measure catch rate per defect class and false rejects per shift — the number operators actually feel — and tune thresholds until the alarm rate earns trust instead of eroding it.

5. Go live and wire the retraining loop (weeks 8–12)

   Connect verdicts to the line, hand operators a one-tap override, and route every correction into the next training cycle. The system's accuracy on day one of production should be its floor, not its ceiling.

What does a vision pilot cost and return?

The return is escapes that never reach a customer, rework that never happens, and inspection labour redeployed — measured against an escape rate recorded before the pilot starts, never estimated after it. Quality-related costs consume 15–20% of sales revenue at many organisations, so the saving is usually a line item finance already tracks rather than a benefit that has to be argued into existence.

Work the arithmetic on one line before scoping anything. A line producing 3.5 million parts a year with a 0.5% escape rate ships roughly 17,500 defective parts; at €40 each in rework, scrap, warranty, and administration, that is €700,000 a year leaving the business through a gap manual sampling was never going to close. Cutting escapes by 80% on the classes the model covers returns €560,000 annually from one line, before counting the inspection hours released.

Against that, pilot cost is dominated by three things: capture hardware for one station, the labelling effort of the quality engineers, and integration into the PLC and the operator station. None of them scale with the number of lines you eventually cover, which is why the second line is markedly cheaper than the first. Track four numbers from week one — escape rate, catch rate per class, false rejects per shift, and added milliseconds per part — and the scale-up decision makes itself.

Where do computer vision projects fail?

Most stalled vision projects fail at the camera or at the operator station, not at the model. Five patterns account for nearly every deployment we are called in to rescue, and four of them are decided before a single image is labelled.

• Capture engineered last — A model cannot recover detail the sensor never captured. Glare on a machined surface, a part arriving at a different angle each cycle, or light that shifts between shifts caps accuracy at a level no architecture change can lift.
• No agreed defect taxonomy — If two quality engineers label the same scratch differently, the dataset encodes the disagreement and the model learns it. Write the classes down, with borderline examples, before labelling starts — it is the cheapest accuracy improvement available.
• Rare defects with no strategy — The defects that matter most occur least. Waiting for natural examples stalls the schedule; seeded parts, augmentation, and anomaly-style models keep the pilot moving while real examples accumulate.
• False alarms nobody tuned — Operators override an over-sensitive system for a week, then stop looking at it entirely. Precision earns trust before recall does: tune conservatively, publish the false-reject rate per shift, and widen only once the numbers hold.
• Verdicts that reach no actuator — A verdict that lands in a dashboard rather than the reject gate, the MES record, or the operator's screen changes nothing at all. Integration is not the last 10% of the project; it is the part that decides whether the other 90% counts.