Edge AI at Industrial Sites: Decide Where the Workload Belongs
Updated: Oct 3
A vibration sensor can send thousands of samples while a maintenance engineer needs only a useful alert. Processing data near the machine may shorten the path to that alert and reduce what must be sent over a cellular link. It does not mean every industrial router can run an AI model, or that a model should control a machine without an engineering review.
Start with one question: what decision will the local workload support? Then trace the data, choose a compute host, define the boundary with the PLC and measure the result. This makes “edge intelligence” a deployment choice rather than an unsupported performance promise.
Trace the Data Before Choosing Hardware
Draw the path from sensor or PLC data point through acquisition, preprocessing, inference, alert delivery and storage. The sensor, PLC and Modbus guide helps distinguish device data roles from network routing. Record the sample rate, data volume, timestamp quality, missing-data behavior and the person or system that will act on the result.
For a pump, a bounded pilot might classify an unusual vibration pattern and create a maintenance alert. The PLC still owns its documented control and safety functions. If the model output is later used to change a setpoint or stop equipment, that becomes a separate controls-engineering and site-authorization decision. NIST SP 800-82 Rev. 3 provides the OT security context for protecting those boundaries.
Decide which data must remain local and which summaries may travel to a central service. A local inference process may continue while the WAN is down, but model updates, fleet oversight or remote support may still require connectivity.
Do not assume a fixed bandwidth saving; compare measured traffic for the original and proposed paths.
Put Inference on the Router or a Separate Gateway?
An industrial router's first job is to maintain and protect connectivity. Some models can host additional software; others cannot. Running a model on the router is reasonable only if the exact hardware and firmware support the runtime and leave enough CPU, memory, storage and thermal margin for routing, VPN and recovery under load. Review the router software components before treating a software label as proof of a specific model capability.
Use a separate edge gateway when the workload needs a different update cycle, accelerator, storage capacity or failure boundary. The router-versus-edge-gateway guide explores that trade-off. Neither layout is universally better: a combined box reduces equipment count, while a separate host can keep inference faults and updates away from the communications path.
Decision point | Combined router and compute | Separate edge gateway |
|---|---|---|
Runtime support | Verify the exact SKU, firmware and supported deployment method | Verify gateway runtime and router-to-gateway network policy |
Resource budget | Test routing, VPN and inference together at representative load | Size compute separately; keep router capacity for connectivity |
Failure and updates | Prove a model failure or update cannot strand remote access | Prove gateway failure does not alter the required network path |
Operations | One device inventory, but coupled maintenance windows | Two devices and a clearer split of ownership |
Commission a Bounded Pilot
Define the baseline. Capture the current process signal, operator response, WAN traffic, latency from measurement to alert and false-alarm cost. State what a useful alert means.
Separate data and control. Use a read-only feed for the first pilot where possible. Limit model credentials and destinations; keep PLC control interfaces outside the inference path unless a reviewed design requires otherwise.
Test the full path. Measure acquisition, preprocessing, inference, queueing and alert delivery together. A model's execution time alone is not the end-to-end response time.
Test degraded operation. Disconnect the WAN, restart the compute host and feed missing or poor-quality data. Define whether the system holds its last result, flags uncertainty or stops generating alerts.
Plan updates and rollback. Record model and data versions, approval, deployment owner, health checks and a known-good rollback. Compare pilot alerts with operator review before enabling any automated action.
The NIST AI Risk Management Framework is a useful reference for documenting intended use, evaluation and ongoing monitoring. It does not certify this pilot or replace site-specific safety engineering.
Choose an Acceptance Gate, Not a Marketing Number
The useful targets depend on the process. Record acceptable missed alerts and false alarms, a measured end-to-end alert time, behavior during WAN loss, resource headroom and the support team's ability to diagnose and roll back a faulty model. Test with representative site data and operating conditions. A claim of sub-millisecond response, fixed cloud savings or reduced downtime requires its own measured scope; this article makes none.
Keep the router's firewall, VPN and management access restricted while the pilot runs. If a model is promoted into a control loop, review it with the machine owner and controls engineer as a new system function. Edge placement does not remove responsibility for data quality, security or human decision rights.
FAQ
Does edge AI require a continuous internet connection?
Not for every inference design. A supported local runtime can process data during WAN loss, but updates, central monitoring and remote support may need connectivity. Test offline behavior explicitly.
Can any industrial router run an AI model?
No. Verify the exact hardware, firmware, runtime, resource limits and update method. If these are uncertain or the workload is heavy, assess a separate gateway.
Should a model replace PLC safety logic?
No. Keep the PLC's approved control and safety functions in their documented system. Any model-driven action requires separate controls and site review; an alert-only pilot is a smaller first step.
How can we tell whether local processing saves cellular data?
Measure the same workload before and after the change, including telemetry, alerts, retries, model updates and remote support traffic. Report the test period and operating conditions with the result.
