Key Points
- Edge AI runs machine learning models on hardware near the machine (a sensor, a gateway, or an industrial PC); cloud AI runs them in a remote data center with more compute and data from many sites.
- The right split depends on latency, bandwidth, connectivity, and data governance. For mechanical faults that develop over days or weeks, how often an asset is measured matters more than milliseconds.
- Tractian uses a cloud-analysis design: the sensor captures data on the asset, a gateway relays it over 4G/LTE, and the AI analysis runs in Tractian's cloud, with no plant Wi-Fi required.
Edge AI for industrial plants means running AI models on plant-floor hardware, next to the equipment they watch. A model that classifies bearing faults or flags cavitation runs on a sensor or a nearby gateway, so the first decision about a machine's condition happens on site.
Cloud AI moves that decision to a remote data center. Neither is better in general: raw vibration data from one sensor can add up to gigabytes a day, many sites have weak or locked-down networks, and fleet-wide models need data from many plants.
Edge vs Cloud AI: The Core Tradeoff
Edge AI trades compute power for speed, lower bandwidth, and network independence; cloud AI trades some independence for large-scale compute, fleet-wide data, and easier model updates. The right split depends on which of four factors weighs most at your site: latency, bandwidth, connectivity, and data governance.
| Factor | Edge AI (on or near the machine) | Cloud AI (remote data center) |
|---|---|---|
| Latency | Decision made on site, without a round trip | Depends on the network path and queueing |
| Bandwidth | Sends features, summaries, and alerts | Needs raw or near-raw data to be uploaded |
| Connectivity | Detection can continue during network gaps | Analysis waits for buffered data when the link drops |
| Data governance | Less data leaves the site | Data is stored off site, usually in a chosen region |
| Compute | Limited by small, low-power hardware | Large models and long histories are practical |
| Model updates | Must be pushed out to devices | Updated once, centrally |
| Fleet view | Sees one asset or one site | Compares thousands of similar assets |
A bandwidth example (illustrative)
The arithmetic below is illustrative. It shows why raw vibration streaming does not scale, using round numbers rather than any vendor's specifications.
- A triaxial vibration sensor sampling at 25,600 samples per second per axis, at 2 bytes per sample, produces 3 × 25,600 × 2 = 153,600 bytes per second.
- Streamed around the clock, that is roughly 13 GB per sensor per day.
- Across 200 monitored assets, it approaches 2.7 TB per day.
Real systems do not stream like this. They sample in bursts, and many compute features such as RMS, kurtosis, and spectral peaks at the edge before sending a small summary plus an occasional raw waveform. Burst sampling cuts data volume whether the model then runs at the edge or in the cloud.
When Edge Inference Makes Sense
Edge inference makes the most sense when an event needs a local response in seconds, when no reliable link to the cloud exists, or when policy requires raw data to stay on site. Each case looks different depending on the asset and the site.
Millisecond alerts: where they apply and where they do not
Millisecond response matters for machine protection, such as tripping a turbine or a large compressor when vibration spikes past a safe limit. Those protection systems are usually hardwired and run separately from AI condition monitoring, and they should stay that way.
Condition monitoring is different: most mechanical faults on motors, pumps, fans, and gearboxes develop over days or weeks, so catching the change soon after it starts matters more than milliseconds.
Edge inference can help with fast changes, such as cavitation starting after a suction valve is throttled. Frequent captures sent to the cloud can catch the same change within minutes, which is soon enough for most rotating equipment.
Plant network restrictions
Many plants separate their operational technology (OT) network from the corporate IT network, often in layers, with tight rules about what can talk to what. Control systems for industrial automation sit inside those layers, and IT teams are rightly reluctant to add internet-connected devices there.
Getting a new device approved on the plant network can involve security reviews, firewall changes, and sign-off from both IT and OT owners. Edge AI reduces how much data needs to move, but it does not remove the network question. A separate path such as cellular keeps the monitoring system off the plant network, whether analysis runs at the edge or in the cloud.
When Cloud Analysis Makes Sense
Cloud analysis makes sense when the model benefits from more compute and more data than a sensor or gateway can hold, and when faults develop slowly enough that a short transmission delay does not matter.
- Larger models. Classifying a fault across vibration, ultrasound, temperature, and magnetic field data at once takes more memory than a battery-powered sensor offers.
- Fleet comparison. A failure pattern confirmed on a pump at one plant can inform alerts on similar pumps elsewhere, which needs data in one place.
- Central model updates. A retrained model is deployed once, with no firmware push to thousands of devices.
- Battery life. Sensors that capture and transmit, without running heavy models, can spend their power budget on sampling.
Data sovereignty and governance
Some companies and jurisdictions set rules about where operational data is stored and who can access it. Processing at the edge means raw signals can stay on site, while only features, alerts, and selected waveforms leave.
How Edge AI Architecture Works
An edge AI system for industrial condition monitoring moves data through four stages: sensor, edge gateway, local inference, and alert, with the cloud handling heavier analysis and model management. The table after the steps shows what typically runs where.
- Sensor. Industrial IoT sensors on the asset measure vibration, temperature, current, ultrasound, or a combination. Some sensors compute basic features on board.
- Edge gateway. A gateway collects data from nearby sensors over a short-range wireless link, buffers it, and forwards it. In some designs it also runs inference; in others it only relays.
- Local inference. Models compare the latest features with the asset's baseline and with known fault signatures, and decide whether something has changed and what it might be.
- Alert. If the model finds a developing fault, it produces an alert with the asset, the suspected failure mode, and the supporting evidence, which is then routed to the maintenance team.
What runs at the edge vs in the cloud
| Task | Edge | Cloud | Why |
|---|---|---|---|
| Signal capture and quality checks | Must happen at the sensor | ||
| Feature extraction (RMS, kurtosis, FFT, envelope) | Sometimes | Cuts data volume before transmission | |
| Anomaly detection against the asset's baseline | Fast local flag, confirmed with more context remotely | ||
| Fault classification (bearing, imbalance, misalignment) | Often | Lightweight models locally, larger models centrally | |
| Fleet comparison across similar assets | Needs data from many sites | ||
| Model retraining | Needs labeled data and significant compute | ||
| Work orders, dashboards, reporting | Shared across teams and sites |
The exact split varies by vendor. When you evaluate a system, ask for this table filled in for their product, because it determines what still works when the connection drops.
The same principles apply across predictive maintenance; the guide to AI predictive maintenance covers the detection side.
Where Tractian Fits: Capture at the Asset, Analysis in the Cloud
Tractian splits the work between capture and analysis. The Smart Trac Ultra sensor captures vibration, ultrasound, temperature, and magnetic field data on the asset, sampling from 0 Hz to 64,000 Hz. A gateway relays that data over 4G/LTE to Tractian's cloud, where the AI analysis runs.
Filled in for Tractian, the table above reads: capture and relay at the asset, then feature analysis, fault classification, fleet comparison, retraining, and work orders in the cloud. Tractian does not run its fault models on the sensor or the gateway.
What that design trades:
- Gains: models that use several signals together, comparison against similar assets, central updates, and a three- to five-year sensor battery life.
- Depends on: cellular coverage at the gateway location. Readings wait for the link when coverage drops.
- Unchanged: fast machine protection, such as a vibration trip on a turbine, stays in the control system.
The sensors are rated IP69K and certified for Class 1 Div 1 hazardous locations, Tractian holds SOC 2 and ISO 27001 certifications, and Tractian's standard deployment gets customers fully operational within 14 days.
Cellular Connectivity: Why It Bypasses Plant Network Restrictions
Cellular connectivity sends sensor data over a mobile carrier's network instead of through the plant's LAN, so IT does not need to open firewall ports or put new devices on the plant or OT network. For many plants, that shortens a long network approval process to a much simpler review.
In Tractian's case, the gateway sends data over 4G/LTE, so no plant network access or plant Wi-Fi is required, and the monitoring system and the plant's control network stay separate.
What IT and security teams usually ask
A cellular-first design still needs security review, with different questions. Get written answers from any vendor.
- Does any device connect to our network? In a cellular-first design the answer should be no; confirm it in writing.
- How is data encrypted in transit and at rest?
- Where is data stored, and in which region?
- Who at the vendor can access our data, and how is access logged?
- How are device firmware and models updated?
Coverage is the practical constraint
Cellular depends on signal. Steel buildings, basements, pump pits, and remote sites can have weak coverage. Ask how the vendor checks coverage before installation, what options exist for low-signal areas, and how data is buffered when the link is weak, so readings are not lost.
Hybrid Edge-Cloud Architecture
A hybrid architecture uses the edge for real-time detection close to the asset and the cloud for model retraining on aggregated fleet data. Each side does the work it is suited for, and the two are linked by a feedback loop.
The feedback loop
- A developing fault on a gearbox is flagged, at the edge or in the cloud, and features and a waveform are stored centrally.
- The platform classifies the fault with more context, such as the asset's history and similar gearboxes in other plants, and opens a work order.
- A technician inspects the gearbox and records what was found: confirmed gear wear, a different fault, or nothing.
- That confirmed result becomes a labeled example.
- Models are retrained on labeled examples from across the fleet, and edge designs push them back to devices.
Plants most often skip step 3, and without it the same false alarms come back.
How this fits the wider stack
Edge-cloud splits sit inside the broader AIoT model, where connected devices and AI work together. For how this architecture feeds day-to-day monitoring, see the AI condition monitoring guide. For the physics that edge models detect, see the AI fault detection guide.
Edge AI Readiness Checklist for Plant and IT Teams
Before choosing an edge, cloud, or hybrid system, work through these questions with maintenance, OT, and IT in the same room.
- Which assets come first? Rank critical rotating equipment by consequence of failure.
- What signals do they need? Vibration for bearings and alignment, current for motor electrical faults, temperature and ultrasound for lubrication.
- What is the connectivity path? Plant network, separate network, or cellular, with coverage confirmed at the asset.
- What must keep working offline? Local detection, local storage, or only buffering.
- Where may data live? Get IT and legal sign-off on storage location and access.
- Who closes the loop? Assign who records inspection results so models improve.
Edge and cloud AI are layers of physical AI in plants; the physical AI guide for manufacturing explains the full sensor-to-decision stack, and the industrial AI guide covers the wider set of applications.
Frequently Asked Questions
What is edge AI in manufacturing?
Edge AI in manufacturing is the practice of running AI models on hardware inside the plant, close to the machines, rather than only in a remote data center. Common uses include condition monitoring on motors, pumps, and compressors, and visual inspection on production lines. It reduces data transfer and keeps detection close to the equipment.
What is the difference between edge AI and cloud AI in manufacturing?
Edge AI makes decisions on site, using small, low-power hardware near the asset. Cloud AI makes decisions in a remote data center with far more compute and data from many sites. Most industrial systems combine them: edge for detection close to the machine, cloud for fleet comparison, reporting, and retraining.
Does edge AI work without an internet connection?
Local inference can keep running when the connection drops, because the model sits on site. What stops is whatever depends on the cloud, such as dashboards, fleet comparisons, and remote notifications, until the link returns. Ask each vendor what is buffered locally and for how long.
What is edge AI condition monitoring?
Edge AI condition monitoring uses sensors and nearby processors to analyze machine signals, such as vibration, temperature, and current, at the plant. The edge extracts features and flags developing faults, then sends alerts and summaries onward. This cuts bandwidth and shortens the time from a change in the machine to an alert.
Is edge AI more secure than cloud AI?
Edge AI reduces how much raw data leaves the site, which narrows some risks, but security depends on the whole design. Device hardening, encryption, firmware updates, and how the system connects to the outside each matter. A design that keeps devices off the plant network, such as one using cellular connectivity, avoids adding new paths into the control network.
What hardware does edge AI need in an industrial plant?
A typical setup has sensors mounted on the assets and one or more gateways that collect sensor data and forward it. Inference runs on the sensor, the gateway, an industrial PC, or a mix. Hardware must handle the plant's temperature, dust, moisture, and vibration, and be rated for hazardous areas where required.
How does industrial IoT relate to edge AI?
Industrial IoT is the network of connected sensors and devices on equipment. Edge AI is the intelligence that runs on or near those devices to interpret their data. Together, they let a plant detect equipment problems from sensor data without sending each raw reading to the cloud.
Does Tractian run AI on the sensor or in the cloud?
In the cloud. The Smart Trac Ultra sensor captures vibration, ultrasound, temperature, and magnetic field data on the asset, a gateway relays it over 4G/LTE, and the AI analysis runs in Tractian's cloud. Plant Wi-Fi is not required. Fast machine protection trips stay in the plant's control system.
See how Tractian detects failures before they happen. Explore Condition Monitoring