A recognition model that scores 98% on your offline validation set can still stall the line. The reason is almost never accuracy. It is that “real time” was treated as a property of the model instead of a property of the loop the model runs inside. On an inspection line, real-time object recognition means one thing: the pipeline keeps pace with the conveyor and emits a per-unit verdict inside the line’s cycle time. A recognition result that is correct but arrives two units late is not a real-time result — it is a delayed one, and by the time it lands the part it describes has already passed the reject gate. The distinction sounds pedantic. It is the difference between a system operations can act on and one that produces clean-looking dashboards while defects keep shipping. What does real-time object recognition actually mean on a line? Strip away the marketing and there are two independent requirements that get collapsed into one word. The first is latency: the elapsed time from frame capture to verdict emission for a single unit. The second is throughput: how many units per second the pipeline can sustain without falling behind. A model can be fast on latency and still fail on throughput if inference cannot run back-to-back at line speed, and it can sustain throughput while individual verdicts arrive too late to gate the correct part. Both have to fit the line’s cycle time, and neither is captured by a benchmark accuracy number. Cycle time is the budget. If a conveyor presents one unit every 250 ms, then frame capture, pre-processing, inference, post-processing, and verdict emission all have to complete inside that window — with margin for the reject actuator to fire before the part leaves the gate. Real time here is defined by the conveyor, not by the GPU spec sheet. This is the same framing we apply to real-time object detection on the production line; recognition adds the constraint that the identity of the part, not just its bounding box, has to resolve inside the same budget. Recognition, detection, classification: why the distinction matters here Teams use these terms interchangeably in conversation, then discover on the line that they behave very differently under a latency budget. Detection answers where — it localises objects (bounding boxes) in the frame. On a line this is what finds candidate parts or candidate defect regions. Classification answers what kind — given a crop, which category does it belong to. Recognition in an inspection context is the combined job: locate the specific unit and resolve its identity or condition well enough to emit a verdict on that unit. It usually chains a detector with a classifier, or runs a single model that does both. The chaining is where latency budgets get spent. A detect-then-classify pipeline runs two inference passes; a unified detector like a YOLO variant folds them into one. That architectural choice is a throughput decision before it is an accuracy decision. If you want the mechanics of how the detection stage itself works, how an image detection model works in industrial inspection covers the localisation half, and YOLO inference explained for industrial CV inspection covers the single-pass route. The verdict has to be shaped for SPC, not just correct Here is the failure that quietly undermines otherwise good pipelines: the recognition result is accurate but arrives in a shape operations cannot trend. A verdict that feeds statistical process control has to be per-unit, timestamped, and ordered. Each physical unit that passes the camera gets exactly one verdict record, stamped with a capture time and a stable unit identifier, so that a defect-rate control chart can plot pass/fail over time and detect drift. A pipeline that emits aggregate counts per shift, or that occasionally emits two verdicts for one unit, or that lets verdicts arrive out of order under load, produces a stream SPC tooling cannot chart cleanly — even when every individual classification is right. The design implication is concrete: the recognition loop is not done when it produces a label. It is done when it produces a timestamped, per-unit record on an ordered stream. That stream is the raw input a monitoring harness trends for drift, which is why we treat verdict logging as part of the recognition specification rather than a downstream afterthought. Linking parts to stable identities across frames — the job covered in Re-ID in CV inspection for SPC — is often what makes “one verdict per physical unit” achievable when the camera sees each unit in multiple frames. A worked latency budget Assume a line running one unit every 200 ms (5 units/second) and a single-camera station. The numbers below are illustrative — a worked example to show how the budget is allocated, not measured values from a specific deployment. Stage Illustrative time Notes Frame capture + transfer ~15 ms Camera exposure + PCIe/GigE transfer to host Pre-processing (resize, normalise) ~10 ms On GPU where possible to avoid host round-trips Inference (detect + recognise) ~90 ms The main variable; depends on model + runtime Post-processing (NMS, verdict logic) ~15 ms Non-max suppression, threshold, unit association Verdict emission + logging ~10 ms Timestamped record onto the ordered stream Total ~140 ms Leaves ~60 ms margin before the 200 ms deadline The margin matters as much as the total. A pipeline that averages 140 ms but occasionally spikes to 220 ms under garbage-collection pauses, thermal throttling, or a batch stall will silently drop the correct verdict window for those units. Real-time behaviour is about the worst-case tail, not the average — the average looks fine right up until the line stops. What hardware and pipeline choices actually move the budget The levers that change the numbers above fall into a few clear categories. Edge inference vs. offloading. Running inference on a station-side GPU or industrial edge box removes network round-trips to a central server. This is usually the single largest latency win, and it also removes the failure mode where a shared server’s load from another line inflates your tail latency. Runtime and graph optimisation. The same model weights run faster through an optimised inference runtime. Converting a PyTorch model to TensorRT or ONNX Runtime, applying kernel fusion, and using reduced precision (FP16 or INT8) where accuracy tolerates it typically cuts inference time substantially compared to an unoptimised eager-mode forward pass — an observed pattern across CV deployment work, not a fixed benchmarked ratio, since the gain depends heavily on the model and the target device. The precision choice is a genuine trade-off, not a free win: INT8 quantisation can shift borderline verdicts, which is exactly why validation at full line speed matters (below). Batching. Batching improves GPU throughput but adds latency, because the pipeline waits to fill a batch before running inference. On a line where each unit needs its verdict before the reject gate, large batches are often the wrong call — they optimise the throughput number while blowing the per-unit latency deadline. Small or single-unit batches are common on tight-cycle lines for exactly this reason. Frame skipping and resolution. Dropping frames or downscaling buys headroom, but on a recognition task both can quietly cost accuracy on small or subtle features. This is a decision to make with eyes open, not a default. Validating that accuracy holds at line speed The most consequential gap between offline evaluation and line reality is that accuracy measured on a static validation set does not guarantee accuracy at full speed. Motion blur, lighting variation, partial occlusion as units jostle on the conveyor, and the precision cuts introduced to hit the latency budget all degrade recognition in ways the offline set never showed. The validation that matters is a run at full line speed against a known-labelled batch of physical units, with verdicts logged exactly as they would be in production. Compare the live verdict stream against ground truth and check the timing distribution — a verdict that is correct but arrives after the deadline should be counted as a miss, because operationally it is one. A pipeline that holds 98% offline and drops to 91% at speed has not “lost accuracy”; it has revealed the accuracy it will actually deliver. This is the point where recognition engineering meets reliability engineering. The latency and throughput targets, and the shape of the verdict stream, are among the inspection artefacts a hardened industrial CV deployment signs against — see our work on [inspection reliability artefacts](production AI reliability) for how those commitments get formalised. For the broader picture of how these pieces assemble into a deployable system, our computer vision practice and the way we scope these engagements around your specific line are the starting points. FAQ How does real time object recognition actually work? It combines locating a specific unit in the frame with resolving its identity or condition, then emits a verdict for that unit. In practice “real time” means the whole loop — capture, inference, verdict emission — completes inside the line’s cycle time so the result can gate the correct part, not just that inference is fast in isolation. What latency and throughput targets make object recognition ‘real time’ for a specific line cycle time? The budget is set by cycle time: if the line presents a unit every 200 ms, every stage from frame capture to verdict emission must complete inside that window with margin for the reject actuator. Latency (per-unit elapsed time) and throughput (sustained units per second) are separate requirements, and both have to fit — a model can pass one and fail the other. How does a real time recognition verdict get logged so SPC tools can chart defect rate over time? Each physical unit gets exactly one verdict record, timestamped with its capture time and a stable unit identifier, emitted onto an ordered stream. That per-unit, timestamped, in-order shape is what lets a control chart plot pass/fail over time and detect drift. Aggregate counts or out-of-order records break SPC trending even when each classification is correct. What hardware and pipeline choices affect real time recognition on the line? Edge inference removes network round-trips and is usually the biggest latency win; runtime optimisation (TensorRT/ONNX, kernel fusion, FP16/INT8) speeds inference at some accuracy risk; batching helps throughput but hurts per-unit latency; frame skipping and downscaling buy headroom but can cost accuracy on subtle features. Each is a trade-off against the cycle-time budget, not a universal default. How do you distinguish real time object recognition from real time object detection and classification? Detection answers where (localisation), classification answers what kind (given a crop), and recognition on a line is the combined job of locating the specific unit and resolving its identity well enough to emit a per-unit verdict. Recognition often chains a detector with a classifier, which spends more of the latency budget than a unified single-pass model. What happens to SPC drift detection if recognition latency degrades or verdicts arrive out of order? Drift detection depends on a clean, ordered, per-unit verdict stream; if latency spikes push verdicts past the deadline or reorder them, the control chart is fed corrupted data. The result is either false drift signals or missed real drift — the SPC layer trusts the stream, so a timing failure in recognition surfaces as a monitoring failure downstream. How do you validate that a real time recognition pipeline holds its accuracy at full line speed? Run the pipeline at full line speed against a known-labelled batch of physical units, logging verdicts exactly as production would, then compare against ground truth and the timing distribution. Count late verdicts as misses. Offline accuracy on a static set does not predict line accuracy, because motion blur, occlusion, and the precision cuts made to hit the budget only show up at speed. The uncomfortable question to carry into any line-speed scoping conversation is not “is the model accurate enough?” — it is “what does the line’s cycle time budget leave for inference, and does the verdict stream come out in a shape SPC can trend?” Answer those two, and the accuracy question mostly takes care of itself.
