Updated July 2026 · 7 min read · Adente Vision Engineering Team
Why does anomaly detection run on every part, not a sample?
Anomaly detection earns its value precisely because it inspects every part, not a statistical sample. Its job is to catch the rare, first-seen flaw that a rule was never written for, and a defect you cannot predict is one you cannot afford to sample past. The one part you skip is exactly the one the anomaly model exists to flag.
That is different from a periodic gauge check or an audit, where sampling is defensible because the thing being measured is stable and known. An anomaly is neither. It appears without warning, in a place no one specified, which means the only honest coverage is 100 percent: decide on this part, now, before the next one indexes into frame.
The consequence for architecture is direct. If every part needs a decision, the decision has to fit inside the time between parts. That is the constraint that turns the edge-versus-cloud question from a preference into a timing problem.
What is the per-part time cost at line speed?
At line speed, the budget for each part is the gap between parts, and it is short. On a line running 100 or more parts per minute, the whole loop, capture, inference and a pass or fail signal, has to complete inside well under a second, per part, without falling behind. There is no room to average the slow parts against the fast ones; every part must clear.
The measured field result for an Adente unit is about 30 ms per part, and the catalog bound is a conservative 0.5 s per part at 100 or more parts per minute. Treat those as the envelope. The number you can actually commit to for your own cell depends on your parts, your lighting and your cycle, and it needs an application-specific measurement rather than a figure copied from a datasheet.
What matters for the cloud question is not the exact millisecond but the shape of the budget: it is tight, it is per part, and it repeats without a break. Any element in the loop that cannot promise to finish inside that window, every time, breaks it.
Why is a cloud round-trip unacceptable per part?
A cloud round-trip is unacceptable per part because its timing is unbounded, and a per-part budget cannot absorb an unbounded step. Sending each frame off the line means it waits for the network, a queue, a shared inference host, and the return trip, and none of those has a hard ceiling you can guarantee on every cycle. Average latency is not the problem; the tail is. The occasional slow round-trip is the part that misses its window.
Edge inference removes the round-trip entirely. Adente Vision is an edge-AI visual inspection unit built by ADENTE Advanced Engineering Technologies, part of the Aden Group, sold through automation system integrators. It captures, decides and emits the verdict on the unit, so the timing is set by local compute rather than by a network you do not control. Deterministic real-time fieldbuses exist for the same reason: industrial timing has to be bounded, and a public network hop is the opposite of bounded.
There is also a data reason that rides along with the timing one. Because the frame never leaves the line to reach a decision, the sensitive part image stays local as a side effect of the architecture that keeps it fast. Speed and data residency point the same way here.
The per-part decision loop: edge versus cloud
The table walks the same loop under both architectures and shows where the cloud path adds time it cannot bound.
| Loop stage | Edge (on-device) | Cloud round-trip |
|---|---|---|
| Capture | Local, triggered to the part | Local, triggered to the part |
| Get frame to the model | In-memory on the unit | Upload over the network, queue |
| Inference | On the local Jetson-class board | Shared host, variable load |
| Return the verdict | Direct to PLC over fieldbus or I/O | Download back over the network |
| Timing guarantee | Bounded by local compute | Unbounded tail, per part |
How do anomaly, defect, counting and quality share the edge budget?
The edge budget is not spent on anomaly detection alone; it is shared across the modes the unit runs. Adente units offer four modes, Anomaly, Defect, Counting and Quality, and on a given part the relevant checks run inside the same per-part window on the same local board. The budget is a whole-loop budget, not a per-mode allowance you can overspend.
That is an argument for doing the work in one place. When capture, the anomaly pass, and any defect, counting or quality check all happen on the unit, they share memory and compute and produce one verdict per part without a network hop between stages. Splitting the modes across a local capture and a remote model would reintroduce exactly the round-trip the per-part budget cannot afford, and it would do so on every part rather than occasionally. See how the unit runs the four modes on one board on the system overview.
Where does the cloud still help?
The cloud is not useless here; it is just on the wrong side of the per-part loop. Where it genuinely helps is offline: training and improving the model, which is not time-critical and does not run on every part. Retraining on a fresh set of examples can happen off the line, on a schedule, without any part waiting on it.
That is the clean division of labor. The per-part decision stays on the edge because it has a hard, repeating deadline; the occasional model update happens away from the line because it does not. For the mechanism behind training an anomaly model from a small set of good parts, see the sibling post on inspecting with 20 images, and for the wider architecture, the pillar guide on AI visual inspection.