Updated July 2026 · 7 min read · Adente Vision Engineering Team
Why is network dependence an availability risk for inspection?
Every network hop between a camera and the decision that stops a bad part is a single point of failure. If the pass/fail is computed somewhere other than the cell, then a switch, a firewall, a WAN link, a cloud region and a shared server all sit between seeing the part and acting on it, and any one of them going down takes the inspection with it. For a line that must not ship an uninspected part, that is not a performance question, it is an availability question.
Availability is usually quoted as the percentage of scheduled time a system is able to run, and published figures for well-run production equipment commonly sit in the high-90s percent. That number is an industry range, not an Adente claim, and it depends on the line. What matters for architecture is simple: every dependency you add to the inspection path can only lower it, because the cell is then only as available as its weakest remote link.
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, and it is designed so the inspection decision has no remote dependency to lose.
What happens to a cloud inspection pipeline when the WAN goes down?
When the wide-area network drops, a cloud inspection pipeline stops making decisions. The camera may still capture, but the frames have nowhere to go, the model cannot be reached, and the pass/fail never comes back. The cell is then left with two poor options: hold the line until the link returns, or keep running and let parts through without inspection. On a quality-critical line, both are expensive, one in downtime, the other in escapes that surface later as returns or a recall.
A WAN outage is also the failure you least control. It can come from the plant's ISP, a provider-side incident, a routing problem or scheduled maintenance in a region far from the factory floor, none of which the production team can fix while the line waits. Designing the inspection so it never needs that link is the only way to take the outage off the critical path.
How does a self-contained edge unit keep inspecting offline?
A self-contained edge unit keeps inspecting because capture, decision and logging all happen inside the enclosure. The image is taken, the hybrid classical-plus-AI model classifies it, the pass/fail is emitted to the PLC over discrete I/O or fieldbus, and the result is recorded locally, all without a call leaving the line. Inference runs on a fanless Jetson-class board of 8-16 GB inside the unit, so there is no server to reach and nothing to time out.
The result reaches the controller on the plant's own network. The unit signals pass/fail over PROFINET, EtherNet/IP, Modbus TCP, EtherCAT or OPC UA, or over 4 inputs and 4 outputs at 24V, none of which needs a route off the floor. Because model updates arrive by USB stick rather than a live connection, a cell can run with no outbound network at all and still get full AI inspection, and the remote dashboard becomes a convenience for monitoring rather than a dependency for deciding. When the network is healthy the unit reports metrics upstream; when the network is down it carries on inspecting and holds the results until the link returns.
Inspection uptime versus line uptime: what are you protecting?
Inspection uptime and line uptime are different metrics, and the edge design protects the one that carries quality risk. Line uptime is whether the line is producing; inspection uptime is whether every part that runs is actually being checked. A networked pipeline can fail in a way that keeps the line moving while inspection is silently down, which is the worst case, because uninspected parts ship looking fine until a customer finds the defect.
| Failure event | Cloud or networked pipeline | Self-contained edge unit |
|---|---|---|
| Internet or WAN outage | Inspection stops; parts pass uninspected or the line halts | Keeps inspecting; the decision is made locally |
| Plant LAN switch failure | Loses the camera-to-server link | Pass/fail unaffected; the unit decides on-board |
| Cloud provider or region incident | Pipeline down until the provider restores it | No dependency; nothing external to restore |
| Server or VM maintenance window | Scheduled downtime for inspection | Runs through it on the edge |
| Remote dashboard unreachable | Can block the decision path | Dashboard is monitoring only; the decision continues |
Keeping the decision on the edge collapses the gap between the two metrics: if the unit has power and a trigger, it is inspecting, so inspection uptime tracks the cell rather than the plant's IT. That is why network dependence belongs on the availability risk register next to mechanical faults, not treated as a separate IT concern.
How do you buffer and reconcile results after an outage?
The pattern is to decide locally and reconcile later. During an outage the unit keeps emitting pass/fail to the controller in real time and stores each result and its metadata on-device, so no part is missed and no decision waits on the link. When connectivity returns, the buffered records sync to the dashboard or MES, and the fleet view catches up without any raw frames having to move.
That separation, a real-time local decision plus a deferred metric sync, is what lets one architecture serve both a fully air-gapped line and a connected one. The decision path never depends on the network; only the reporting path does, and the reporting path is allowed to be late.
For the broader trade-off behind this, see the sibling post on edge vs cloud visual inspection; for the full method, see the pillar guide on AI visual inspection.