Edge AI & IoT
Edge AI or cloud AI: where should operational monitoring run?
Start with the decision your team needs to make, then decide where inference belongs. A local alert and a cross-site report may need different architectures.
- Camera / sensor
- Local inference
- Operational response
An operational monitoring project starts with an event: a person enters a restricted area, a machine changes state, or a sensor reading needs attention. The useful question is what must happen next, and whether that response can wait for an internet connection.
Our recommendation is to separate the immediate response from the longer-term analysis. Evaluate local inference when the response must continue through a network outage. Evaluate cloud processing when the work can tolerate network delay and needs information from several locations. A hybrid design is worth testing when both requirements exist. This is an architecture recommendation, not a claim that one approach always costs less or performs better.
What runs where
Edge inference means running a trained model near the source of the data. That might be an industrial computer receiving camera streams or a gateway connected to sensors. Training and inference need not happen in the same place. AWS documents a Greengrass pattern in which models trained in the cloud run on local devices.
For a hypothetical loading-bay monitoring system, a local device could evaluate a camera feed and send selected events upstream. A central application could then help an operator compare events across sites. This describes a possible architecture, not an AMMEGATECH customer deployment.
Choose around operational constraints
Use this decision matrix to prepare a pilot. It expresses evaluation priorities, not guaranteed product characteristics.
Scroll sideways to compare all columns.
| Requirement | Candidate approach | What to prove |
|---|---|---|
| Alerts must continue without internet | Local inference and a local alert path | Disconnect the uplink and check the full response, not just the model |
| Teams need cross-site analysis | Central processing or a hybrid design | Check synchronization, timestamps and missing-event handling |
| Raw video should remain on site | Local processing with explicit upload rules | Inspect transmitted data, logs and diagnostic uploads |
| Sites have limited technical support | Compare managed cloud and managed edge options | Confirm who patches, monitors and replaces each component |
| Workloads change frequently | Compare update and rollback workflows | Deploy a model revision and recover from a failed update |
Local processing alone is not evidence of privacy or security. The proposal still needs a data-flow inventory: what is captured, what is retained, who can access it and what leaves the site. Apply the same questions to screenshots, logs and support sessions.
Design for a connection failure
Offline operation needs an explicit design. Microsoft’s IoT Edge documentation describes local communication and queued upstream messages after initial synchronization. It also identifies storage capacity and message time-to-live as limits on retaining those messages.
For a pilot, specify the longest outage you intend to support and test it. Watch the queue fill, restore connectivity, then check whether the system delivers duplicates, loses expired events or overwhelms the receiving service. Define how the operator can distinguish a healthy device from a device whose last report is merely old.
Also separate detecting an event from delivering an alert. A local model may continue running while a cloud notification service is unreachable. If the operational requirement is a local warning, that warning needs a local delivery path and its own test.
Measure the full response
Agree the pass criteria before comparing hardware or models. Record the time from a real event to an actionable notification, the missed events, and the alerts that an operator dismisses. Include low-light conditions, occlusion and the camera angles the site actually uses.
Track ongoing work as well: installation, remote diagnostics, model updates, storage and replacement visits. A cheaper device can be a poor choice if the team cannot maintain it. Conversely, a centralized design may be unsuitable if the uplink cannot carry the required data reliably.
A useful first brief
Bring a representative camera or sensor feed, the required response, an outage scenario and an owner for the operational decision. Document what the pilot must prove before committing to a wider deployment.
MORA EDGE covers computer vision, edge AI and IoT within AMMEGATECH. When monitoring also involves connectivity or enterprise workflows, AMMEGATECH Enterprise provides a place to discuss those combined requirements. The architecture should follow the evidence from the pilot.