Field transmitters with an onboard inference chip that classifies faults, drift and process anomalies locally, before the signal ever reaches the control system.
Edge AI / edge computing platforms for OT analytics
Ruggedised, industrially-rated compute platforms running AI inference physically close to the process — in the control room or on the plant floor — rather than in a distant cloud region.
Short entry. This page summarises our current placement. Full, sourced analyses are published first for the technologies closest to practical use; see the list of full analyses.
How it works
An industrial edge platform is computing placed on site, between the control system and enterprise or cloud systems. The hardware is an industrial computer, often with a graphics or neural processor for inference. The software runs applications as containers, and a central management system deploys, updates and monitors them across many edge devices.
For AI workloads the usual pattern is to train centrally and run locally. Models are developed where data and computing power are plentiful, packaged, and pushed to the edge, where they score live data from cameras, vibration sensors or the control system. Results feed local displays and alarms, and selected data returns upstream to improve the next version of the model.
Why it matters
Delivers low-latency AI analytics (vision, acoustic, vibration) without depending on connectivity to an off-site data centre, and keeps sensitive process data on-site.
Where it fits
Edge computing is the practical home for analytics that need fast response, large local data volumes or independence from an external connection: vision inspection, acoustic and vibration monitoring, soft sensors and local optimisation. It also provides a controlled place to connect operational data to IT systems without reaching into controllers directly.
Why we place it at the Over-Promise stage
Most major automation suppliers offer an industrial edge-compute platform; the constraint is now the software lifecycle (model deployment, monitoring and updates), not the hardware. Estimated time to the Proven in Use stage: 2–5 yrs. What the stages mean.
Key risk
Managing model versions, drift and updates across potentially hundreds of distributed edge nodes is an operational discipline most OT teams are still building.
Questions to ask before committing
- How are applications and models versioned, approved and rolled back across all edge devices?
- Who patches the operating system and container runtime, and how often?
- Where does the platform sit in the network architecture, and what can it write to?
- How is model performance monitored after deployment, and who acts when it degrades?
Standards and terms to know
- Container
- A packaged application with its dependencies that runs in isolation on a shared host.
- MLOps
- The practices for deploying, monitoring and maintaining machine-learning models in production.
- Fleet management
- Central control of software and configuration across many distributed devices.
Related technologies
See this entry on the full maturity map · All IT/OT & CCII entries · How placements are made. Stage and time-horizon placements are editorial judgements based on public information as of October 2026, not engineering, safety or investment advice; see the Terms of Use.