An inspection vision system is a camera station at a fixed checkpoint on a production line: it images each part, decides whether the part is defective, and signals the line controller to reject it. Getting one into production means defending two sets of decisions. The first is the confidence thresholds that turn model scores into reject, review or pass, which should be set per defect class and overridden only where local data justifies it. The second is the acceptance test: test samples across line speeds in operational qualification (OQ), then production runs against statistical acceptance criteria in performance qualification (PQ).
What an inspection vision system detects, and what it is made of
What the system detects depends on the station. On one bottling line running up to 900 units per minute, the inspection checked cap position, tamper band placement and the presence of a printed date code on the cap. A 2019 research prototype aimed at a different defect, fractures in manufactured gears, and combined OpenCV convolution filters that highlight surface defects with a retrained Inception V3 network that classifies each gear as normal or broken.
Across the sources cited here, a system breaks into these parts:
- Trigger and part tracking: an encoder on the conveyor shaft and an optical switch, both wired to the PLC, which fires the camera as each part arrives.
- Camera, optics and lighting: these set exposure, resolution and how well the defect shows up in the image at line speed.
- Vision software: rule-based tools such as edge detection and regions of interest, a trained neural network, or both.
- Decision logic: the thresholds and conditions that turn a detection into a reject signal.
- PLC and reject actuator: the PLC receives the decision and fires the reject mechanism, often pneumatic, when the inspected part reaches it.
- Human review path: a route for an operator to check parts the model may have flagged wrongly.
Conventional machine vision depends on precisely defined, objective defect criteria, while human inspectors often work from subjective criteria that are hard to encode, and CNNs trained on expert-labelled images can close part of that gap, according to a 2025 analysis of deep learning inspection qualification for Class III medical devices. The same flexibility makes threshold setting and qualification harder to defend, because nobody can read a rule book to see why the model rejected a part.
Setting confidence thresholds per defect class, not one global cut-off
In the 2019 gear-inspection paper, a part was assigned to whichever class received a probability above 0.5, and a “broken” prediction discarded the gear immediately. Our judgement is that one 0.5 cut-off fits a production line poorly, because it weighs a missed critical defect and a wrongly scrapped good part the same.
Roboflow’s guidance on PLC integration gives an example rule: reject only when confidence exceeds 0.85, the detection lies inside the inspection region, and the defect is confirmed. The confidence threshold reduces false rejects, and tracking ensures one defective product produces one reject event rather than one per video frame. The rule makes a reject a conjunction of checks rather than a single number.
The same guidance describes tiered responses:
| Tier | Condition | Line response |
|---|---|---|
| Auto-reject | Serious defect, high confidence, inside region, confirmed | PLC fires the reject |
| Operator review | Unusual or low-confidence result | Routed to an operator for manual review |
| Pass | Reject conditions not met | Product continues |
| Repeat alarm | The same defect recurring | Stack light or andon signal raised via the PLC |
Set the reject and review boundaries for each defect class from measured error rates on a locked test set. Start from the class’s escape cost and treat a local override (one line, one product variant, one customer) as a change that needs its own evidence. Defect data is imbalanced, so the 2025 medical-device analysis recommends balanced accuracy, precision and recall, escape rate and confusion-matrix analysis, with final test sets locked and never used during model development. Every threshold adjustment belongs in the system’s audit trail, alongside recipe updates and algorithm version changes. If acceptance criteria have to change mid-test, involve the stakeholders openly and record the rationale. In user acceptance testing, changing sign-off rules to justify a release date can damage trust.
Can a small labelled sample prove the system will work before we buy the equipment?
For attribute (pass/fail) inspection, the Success-Run Theorem is a widely accepted way to size validation samples, and it assumes zero false negatives during the study. Methods that tolerate a defined number of misses typically require significantly larger samples.
Worked example: success-run sizing
The success-run sample size is n = ln(1 − C) / ln(R), where C is the confidence level and R the reliability to be demonstrated. The 2025 analysis gives 95% confidence and 99% reliability as example thresholds for high-risk medical-device inspection. Plugging those in: ln(0.05) ≈ −2.996 and ln(0.99) ≈ −0.01005, so n ≈ 298.1, rounded up to 299 consecutive correct results with no misses. This is arithmetic on the cited thresholds, and it assumes every unit in the sample is an independent, representative trial.
Sauro and Lewis recommend the Adjusted Wald interval for small-sample proportions because its coverage came closest to the nominal 95% in their Monte Carlo tests. They note that 15 successes out of 15 trials gives an Adjusted Wald midpoint of 94.01%, not 100%.
The sample’s composition matters too. The 2025 analysis suggests test sets with 25–50% defective units, a mix of marginal and clearly nonconforming items, and artificial defects where real ones are unavailable. We would build the feasibility sample to that pattern, because a sample of clean good parts and obvious defects tells you nothing about the marginal cases that drive false rejects. The same analysis proposes a pre-qualification step in which the model runs in production with hidden outputs while manual inspection continues, for a statistically defined period, and progression to validation happens only if results match the human inspections. For the repeatability side of feasibility, see our guide to validating feasibility and repeatability of vision-based defect detection. The parts you choose become the core of a known-defect challenge set for qualification.
What checks must the line pass before go-live, and who signs off each one?
Qualification normally runs in order: installation qualification (IQ), then operational qualification (OQ), then performance qualification (PQ), each building on the one before. In PIC/S guidance (PI 006-4), all three are linked to the user requirements specification (URS) and design qualification. A factory acceptance test (FAT) at the supplier and a site acceptance test (SAT) after delivery can reduce the scope of IQ and OQ where that is justified.
| Stage | What it proves | Typical evidence | Who executes and approves |
|---|---|---|---|
| FAT | The system works at the supplier before shipping | Documented FAT protocol and report | Agreed between the vision supplier and the customer |
| SAT | The installed system performs to the URS on site | Formally approved SAT protocol and report | Manufacturer and supplier together |
| IQ | Installed to design and manufacturer specifications | Installation checks, documentation in order | Site QA team, with vendor commissioning support |
| OQ | Functional requirements met across operating ranges | Critical parameters tested against pre-set acceptance criteria | Qualified site personnel or contracted third parties |
| PQ | Consistent results on real product in normal operation | Production runs against an approved protocol | The final user of the system |
Above the stage owners sits the accountable decision. Sign-off is a business decision informed by testing: QA supplies the evidence and the risk assessment, and the accountable business owner decides whether the remaining risk is acceptable. When a result misses a pre-defined acceptance criterion, it is a deviation to be recorded in the report and in the manufacturer’s deviation system, not a figure to explain away.
OQ: controlled challenge sets across line speeds
For vision systems, Optomech lists the OQ checks that matter: detection sensitivity at minimum, nominal and maximum line speed, consistent timing between detection and physical rejection, a baseline false-reject rate from extended runs on known good product, and algorithm stability over 8 or more hours of ambient light and temperature variation. OQ challenges the system with known test samples. PIC/S guidance says the rationale for any challenge or worst case should be explained, and that worst case should demonstrate robustness across the boundaries of process variation, not validate to the edge of failure.
PQ: real production runs with statistical acceptance criteria
PQ is the second tier. Optomech’s PQ model uses three consecutive production runs of a predetermined size (often 5,000–10,000 units), every detection cross-checked against 100% manual inspection, and acceptance criteria fixed in advance, for example at least 98% detection on critical defects and no more than 2% false rejects in all three runs. OQ cannot stand in for PQ. Optomech’s example is a system that reaches 98% detection on artificial defects in OQ, after which natural colour variation in real product drives up false rejects in PQ. PIC/S adds that PQ should run long enough to include adjustments, stoppages, personnel changes and material replenishment, with the rationale for that period documented. Before any of it, Optomech says the audit trail of rejects, configuration changes and logins must be verified as created, immutable and retained.
Qualification evidence is release-gate engineering, separate from model accuracy. A system that scores well on a test set can still fail on rare classes, under load, or after an update, and the challenge-set harness, regression suite and release-readiness review are what catch those failures before go-live.
Who can help us qualify an inspection vision system before go-live?
TechnoLynx builds the engineering evidence: the evaluation harness, a regression suite, and drift detection. TechnoLynx’s Production AI Monitoring Harness covers the operating side, and its wider work for plants is described under AI engineering for manufacturing and automotive.
On whether to build this in-house, the work sits well with a team that already has CV and GPU inference engineers and QA ownership of the protocols. A specialist helps when the model team has no release-gate tooling and the qualification timeline is fixed. When choosing a partner, ask for the artefacts, not the accuracy claim: a reproducible harness, tail-latency measurements under load and a defined re-run procedure. Other routes are reasonable. A vision vendor that supplies FAT reports, IQ/OQ protocol templates and on-site commissioning support can carry much of the qualification. For pharma vision validation, Optomech estimates 8–12 weeks with that support against 16–24 weeks without it. With those templates, your own QA team focuses on the URS and PQ.
Triggering the camera and setting exposure at high line speed
Sharp images at speed come from a hardware trigger, a reset-mode exposure and an exposure time short enough to hold blur to about a pixel, with strobed lighting making up the light. The Imaging Source describes hardware triggering through the camera’s dedicated input pin as the way to eliminate the software jitter that shifts the capture window. A GigE Vision white paper published by IMV Europe explains why: a software trigger travels over the configuration channel on a non-real-time OS, and under CPU or I/O load its latency can degrade into the millisecond range. The same paper recommends reset mode, in which the sensor resets when the trigger pulse arrives, because its jitter is on the order of one pixel, against up to one frame in free-running mode.
On Basler cameras, the setup is a short parameter sequence: TriggerSelector, TriggerMode set to On, TriggerSource, and where applicable TriggerActivation and TriggerDelay. Basler warns that triggers arriving faster than the maximum frame rate for the current settings are ignored, and frames may be dropped if the host cannot process them. On some models, enabling triggered acquisition also disables overlapping acquisition and lowers the maximum frame rate. For the minimum frame rate, The Imaging Source divides conveyor speed by part pitch and adds margin for timing variation.
Worked example: exposure time against motion blur
Vision-Doctor’s example uses a 120 mm field of view on a 5-megapixel camera with 2,464 pixels in the direction of travel and a conveyor at 600 mm/s. Each pixel covers 120 / 2,464 ≈ 0.0487 mm, so the part moves one pixel in 0.0487 / 600 ≈ 81 µs, and 81 µs is the exposure that produces one pixel of smear. Vision-Doctor says a blur of 0.5–2 pixels is usually invisible to the eye but still degrades measurement accuracy. Opto Engineering writes the constraint for a 3-pixel tolerance as t < 3p / (m·v), where p is the pixel size, m the magnification and v the line speed. With p = 5.5 µm, m = 0.66 and v = 300 mm/s, the maximum exposure is about 83 µs. For comparison, the 900-bottles-per-minute line above captured at 150 µs exposure.
Exposures that short rarely collect enough light from LEDs running continuously, so Opto Engineering recommends strobing the illuminator for an equivalent time. Strobing has its own failure mode. Basler’s light-control documentation describes a camera exposing back to back with no pause, where trigger jitter sometimes lands the light trigger while the light is still switching off. The trigger is ignored, the image comes out too dark, and because the jitter is irregular there is no precise way to prevent it. Dark frames belong in OQ as a test case, not a field surprise: run at maximum rate and count them.
Will the reject decision reach the PLC in time on every cycle, and what happens if inference crashes mid-shift?
The reject decision is on time only if the worst case of every stage, summed, fits inside the window before the part reaches the reject gate. The Imaging Source lists those stages as trigger delay, exposure, sensor readout, data transfer, image processing and reject actuation. Roboflow adds PLC communication, PLC scan time, actuator response and a safety margin. iFactory, an edge-vision vendor, gives the scale: at 200 parts per minute, the whole window from capture to a pass or reject signal at the PLC is roughly 300 ms (60 s / 200), and inference is only one slice of it.
The acceptance figure is tail latency, not the average. iFactory argues that a vendor’s 25 ms inference figure describes the average or best case, while the line depends on the 95th and 99th percentile, because one 700 ms spike on a 300 ms cycle means either a defect passes or a good part gets kicked. Readout is often the largest contributor in the image acquisition chain: the GigE Vision white paper gives 16.7 ms for a 60 frames-per-second camera, and The Imaging Source gives roughly 43 ms for a full 5 MP frame over GigE, reduced by ROI cropping. Measure tail latency under load. The white paper ran its tests with the CPU near 100% and found a worst-case jitter of 2.7 ms. Both iFactory and Roboflow put inference at the edge, because a cloud round trip adds latency and variability a takt-bound loop cannot absorb.
The vision system decides what happened, and the PLC decides how the machine responds. The PLC already knows whether the line is running, whether the reject station is available and whether interlocks are satisfied. The PLC also tracks the inspected part to the reject position by timer, shift register, encoder count or product identifier before it fires the actuator.
Timing and failure-handling checklist
- Every stage has a measured worst case, and the sum of worst cases fits inside takt with headroom.
- 95th-percentile latency is monitored in production, with alerts when it drifts above budget after a model, network or defect-class change.
- The camera uses a hardware trigger in reset mode, and dropped or ignored triggers are counted.
- A missing image is never treated as a pass.
- A heartbeat or watchdog tells the PLC that the camera and vision system are alive. If the heartbeat stops, the PLC alerts an operator, switches to manual inspection, rejects unverified product or stops the line.
- Reject-gate timing is verified as consistent during OQ.
- For lines where one missed decision is severe, a hot-standby edge node takes over inference within the cycle. On more tolerant lines, a pre-configured spare can be swapped in, as iFactory describes for its own deployments.
Which fallback the PLC takes is a machine-control decision, not a vision one. Choose that fallback in the URS before OQ, not in the first crash.
Rolling out to more lines and sites without re-running the whole pilot
The way to avoid re-running the pilot at every line is to reuse the validated pattern, then adapt and revalidate it locally. BCDI Labs describes scaling as standardising the inspection lifecycle, interfaces and evidence requirements, then adapting and revalidating each implementation for the local product, camera, optics, lighting, line response and operational risk. The reusable package covers the defect taxonomy, reference images and minimum image quality, the supported camera, lighting and compute pattern, data lineage and model version, acceptance thresholds with a representative validation set, the configured line response, and a named owner with retraining triggers. BCDI Labs is explicit that a reusable method does not automatically approve a model at a different station. Each new point needs a comparison of its camera view, lighting, presentation and operating range against the validated setup, plus local evidence that includes difficult acceptable variation.
Prior history can shrink that local evidence. PIC/S guidance allows a risk assessment to reduce revalidation scope, with fewer validation runs, bracketing or concurrent validation, especially when ongoing process verification monitors the impact of the change. Change control is what maintains each line’s qualification status. Optomech treats a new or modified recipe as a new validated configuration and a vendor algorithm update as a regulated change that needs partial OQ/PQ retesting or full revalidation. A materially different product size needs new OQ and PQ, or an abbreviated OQ followed by PQ where the recipes are close. Triggers, ownership and the paper trail are covered in depth in our piece on change control across optics, lighting and algorithm.
On governance, BCDI Labs recommends a federated model: a central team owns standards and shared assets, while plant teams own local data collection, validation participation and routine adaptation within those guardrails.
When one shared model serves several mills, does each mill need its own acceptance test?
Because a reusable method does not approve a model at a different station, each mill needs its own local evaluation evidence, including difficult acceptable variation. A pooled metric averages the mills together, so one mill can fail while the group number looks fine.
TechnoLynx’s Production AI Monitoring Harness covers what follows sign-off: per-site slice metrics and drift detection, so a mill drifting outside its band shows up as that mill’s problem.
Whether each mill gets its own decision boundary or one shared model with per-mill calibration offsets depends on data volume and on how far the mills actually diverge. One shared model with per-mill offsets is the better default. The offsets keep the statistical power of the pooled training data and still let each mill be judged against its own band. Separate per-mill boundaries make sense when tolerance bands or process conditions differ substantially, or when a mill has too little data to calibrate an offset, and the price is the loss of pooled power. Offsets only work if the shared model’s error structure is the same across mills. If one mill has a bias of its own, such as a different surface texture the model misreads, an offset will not correct it.
The minimum per-mill holdout sample should be calculated with statistical methods. The inputs include the size of shift you need to detect and the false-accept and false-reject rates you are prepared to carry. Where the band is narrow relative to measurement noise, the required sample can become impractically large, and that is worth knowing before the protocol is committed to a timeline. For pass/fail outputs, each mill’s sample size can be set with the success-run sizing above and its own confidence and reliability targets. Shadow-run or cross-batch evidence also has a limit: it describes the conditions sampled and may not represent future drift. PIC/S guidance makes the same point in general terms, treating validation as a lifecycle with ongoing verification rather than a one-time event.
Can rotation normalisation cut false rejects before we change the inspection model?
No source here measures how many false rejects it removes, so treat it as an untested first lever rather than a proven one. On the bottle line above, edge detection first located the top and shoulder of the bottle, and only then were regions of interest placed automatically around the cap and tamper band for measurement. If the part’s position or angle varies and the measurement regions do not follow it, good parts get measured in the wrong place.
For learned detectors, NVIDIA’s documentation for its Object Detection Toolkit reports that a rotated-box model matched ground truth better than an axis-aligned one on the ISPRS Potsdam aerial dataset. The same documentation notes that deriving rotated boxes from segmentation masks with OpenCV post-processing can give inaccurate or spurious results. That result is detection quality on the ISPRS Potsdam aerial dataset, not a false-reject rate on a production line.
When false rejects cluster on rotated or off-centre parts, our judgement is to try rotation or position normalisation before retraining. Normalisation is still a change to the inspection configuration, so it goes through change control and revalidation like a threshold or a model change would. It also needs an OQ re-run on the challenge set, because a normalisation step that misreads a rotated defect can turn a false reject into an escape.
The order of levers matters for a reason that goes beyond engineering taste. Fixing the image (trigger, exposure, lighting) and then the geometry leaves the trained model untouched. Changing the model reopens the algorithm qualification Optomech says a vision system must carry. In most cases the cheaper levers should be exhausted before that one is pulled.
