Edge vs Cloud for Predictive Maintenance

Every condition-monitoring project I have been asked to review eventually arrives at the same architectural argument, framed as a fight. One camp wants everything in the cloud, because that is where the analytics and the skills are. The other wants everything at the edge, because the plant network is unreliable, the security team is nervous, and somebody read that edge computing reduces latency. Both are arguing about the wrong thing. Edge and cloud are not competing destinations for a system, they are two places to put each of about ten distinct functions. What stays genuinely hard is not the technical placement, it is whether your organisation is prepared to own and operate the edge estate it is about to create.

The message up front: this is a function-by-function placement exercise, not a binary choice. Latency, the reason most often cited for edge computing in maintenance, is almost never the real driver, because a bearing degrading over weeks does not need millisecond inference. The real drivers are bandwidth against data volume at source, autonomy when the link drops, and constraints on data leaving the site. And the real cost of the edge is not hardware, it is the permanent burden of patching, securing, monitoring and physically maintaining a distributed fleet of computers that somebody has to own.

1. Why edge versus cloud is the wrong framing

The phrase invites a single answer, and a single answer is always wrong for a condition-monitoring deployment, because this is not one workload. It is a chain: acquiring signals, translating industrial protocols, buffering when the onward path is unavailable, reducing raw measurement to meaningful features, running a model, raising an alert, storing history, training and retraining, and presenting the result to people who have to act on it.

Those activities have almost nothing in common. Feature extraction from a high-frequency vibration signal is compute-bound work sitting next to the sensor, on a stream that is expensive to move. Model training wants every asset in the portfolio at once and has no business running in a plant room. Visualisation wants to be wherever the users are, which is increasingly not on site.

So stop designing a topology and start designing a placement table. List the functions, ask each the same questions about volume, bandwidth, autonomy, residency and latency, and record the answer with its reason. What you get is not a diagram someone can argue with on principle, it is a set of individually defensible decisions. It also defuses the organisational argument, because each camp usually turns out to be right about the functions it cares about most.

This article stays platform-neutral. Every major cloud has an edge runtime and a managed way to push models down to a gateway, and every industrial vendor has a gateway product with its own opinions; those are implementation choices that follow the placement decision. The platform-specific shapes are covered separately in the reference architectures for Azure, AWS and Google Cloud, with the platform comparison for anyone still choosing. Do the placement thinking first, because it should not be dictated by whichever licence agreement you happen to hold.

2. The functions you are actually placing

Ten functions, each with a placement decision of its own. If a vendor's architecture diagram does not let you point at each of these and say where it runs, you do not yet understand what you are buying.

• Data acquisition: reading the signal from the instrument, wired sensor, wireless node or controller register. At the edge by definition.
• Protocol translation: turning an industrial protocol into something an application layer can consume. The gateway's core job, at the site, because that is where the protocols terminate.
• Buffering and store-and-forward: holding data locally when the link is down, replaying it in order when it returns. Necessarily local, because a buffer that depends on the connection it protects against is not a buffer.
• Filtering and downsampling: deciding what is worth sending at all. Usually local, since the point is to reduce what crosses the link.
• Feature extraction: converting raw signal into the small set of numbers that carry diagnostic meaning. For high-frequency data, the most important edge function of all.
• Inference: running a trained model to produce a health score, anomaly flag or remaining-life estimate. The most genuinely flexible function, and the one placed for the wrong reasons most often.
• Alerting: turning a model output into a notification and, properly, into a work order in the system of record. Usually central, sometimes duplicated locally.
• Model training and retraining: learning from history across many assets. Almost always central.
• Long-term storage: history for trending, training and audit. Central, with a local retention window as insurance.
• Visualisation and reporting: dashboards, trends, fleet views. Central, because the audience is dispersed and often off site.

Most of that list is settled before any argument starts. The genuinely open decisions are filtering, feature extraction, inference and, to a lesser extent, local alerting. Four decisions, not one.

3. The five forces that actually decide placement

For each open function, five forces determine where it belongs. I ask them in this order deliberately, because the order reflects how often each turns out to be decisive, and the one everyone leads with comes last.

Work those through each open function and placement usually falls out without argument. High-frequency vibration on a metered cellular link: volume and bandwidth both point to edge feature extraction. Daily meter readings on a site with fibre: nothing pushes local, so keep the gateway thin. An offshore platform on satellite whose crew need alarms regardless: autonomy dominates, so inference and local alerting go local even though the analytics are modest.

4. Latency is the most over-cited and least relevant reason

The standard justification for edge computing is latency: decisions must be made in milliseconds, therefore compute must be local. That is correct for a class of problems, namely closed-loop process control, machine safety interlocks, protection relays and motion control, anything where a delayed response has a physical consequence within the same breath. Nobody sensible puts a safety function behind a WAN.

The problem is that maintenance is not one of those domains, and people import the reasoning anyway. A bearing developing a spall degrades over weeks. Lubrication starvation shows up over days. Insulation degrades over months. Corrosion, fouling, filter loading and misalignment progressing into wear are all processes on timescales of days to months. The premise of predictive maintenance is that a detectable interval exists between the first sign of a fault and functional failure, long enough to plan an intervention. If it were milliseconds, prediction would be pointless because you could not act on it. That warning window is what makes the discipline viable, and the predictive maintenance practitioner's guide covers it properly.

So when someone tells me a vibration model must run at the edge for latency reasons, my question is what happens differently if the answer arrives thirty seconds later, or an hour later. On a genuine maintenance use case the honest answer is almost always nothing.

Latency is a seductive argument because it sounds technical and smuggles in an entire distributed-computing estate on a premise that does not apply. I would far rather hear "we are putting inference at the edge because our satellite link is unreliable and operators need alarms regardless", which is a reason you can plan around.

5. Where the edge genuinely wins

None of that means the edge is unnecessary. Five situations make local compute obviously correct.

High-frequency vibration and acoustic data. The strongest case in the domain. A sensor sampling fast enough to resolve the frequencies that matter for bearing and gear diagnostics produces a raw waveform stream of an entirely different order of magnitude to a temperature reading. Streaming continuous waveforms from every machine to a central platform is impractical on most plant networks and pointless on all of them, because the analysis needs not the waveform but a compact set of derived features: spectral band energies, envelope metrics, statistical descriptors. Extracting those locally turns a firehose into a trickle with essentially no diagnostic loss. The same holds for ultrasound. For which techniques produce which kind of signal, see the condition monitoring techniques guide.

Expensive, metered or absent connectivity. A remote pumping station on a cellular plan, a WAN shared with operational traffic that has priority, a client-owned network that charges for transit: every byte you do not send is a recurring saving for the life of the deployment. This is the force that most often decides real designs, and it is far more concrete than latency because someone can put a number on it from the existing telecom bill.

Remote and offshore assets. Offshore platforms, pipeline stations, remote substations, vessels, desert wellheads. Links are narrow and intermittent, and a site visit is a scheduled event rather than a ten-minute walk. These deployments must run largely on their own for extended periods, which pushes inference and local alerting local regardless of how sophisticated the analytics are.

Functions that must not depend on a WAN. If a monitoring function has any role in safety, environmental compliance or protecting equipment from damage, a wide area network must not appear in its dependency chain. In practice I would keep such functions out of the predictive maintenance system entirely, implement them in the control layer where they belong, and let the maintenance system observe them.

Data sovereignty and contractual constraints. Some data cannot leave the site or the country for contractual or regulatory reasons, and where that applies it settles the argument immediately. Test the exact scope, though: often the constraint covers identifiable operational detail rather than derived features or aggregate health scores, which leaves a viable hybrid where raw data stays local and only the abstractions travel.

6. Where the cloud genuinely wins

The cloud's advantages here are less about raw compute than about breadth and lifecycle, and the most important one is routinely undervalued by teams whose instincts were formed in operational technology.

Model training. Occasional, bursty, needs a great deal of history at once, benefits from compute you would never buy for a plant room, and needs data from many assets. There is essentially no argument for training at the edge. Train centrally, deploy the model to wherever inference runs.

Cross-site and fleet-wide comparison. The one I would emphasise most, because much of the real analytical value lives here and it is structurally impossible at the edge. A single gateway can tell you this pump looks different from last month. Only a central view can tell you it looks different from the other forty identical pumps in the portfolio, that one site's chillers degrade faster than another's, or that a model trained on the whole fleet outperforms one trained on a single machine. Population comparison is how you separate a genuine fault from a machine that has always run that way, and how you build models for an asset that has never yet failed.

Elastic compute. Retraining a portfolio, backfilling a feature set after a definition change, re-scoring a year of history against a revised model: large, infrequent jobs. Sizing plant-room hardware for a quarterly workload is a poor trade.

Central lifecycle management. Version control of models and configurations, consistent deployment across sites, observability of what runs where, credential and certificate management, audit. Feasible by hand for a handful of gateways, not for dozens. The irony matters: the more you commit to the edge, the more you need a cloud management plane to keep it under control.

Long-term storage is a separate discussion I will not duplicate, including how historians, lakes and lakehouses divide the work. The maintenance telemetry storage guide covers it, and the SCADA and historian integration guide covers the case where a historian already holds much of what you need.

7. The hybrid pattern most deployments converge on

Work the five forces through the ten functions and most deployments land on a consistent shape, worth stating concretely so you have a default to argue against.

At the site: instruments feed a gateway that terminates the industrial protocols and normalises what it reads. It filters and downsamples anything that does not need to travel at full fidelity, and where the signal is high-frequency it extracts features locally rather than shipping the waveform. It holds a buffer sized to survive a realistic outage, with ordered replay. Where autonomy matters it also runs inference against a centrally trained model pushed down to it, and can raise a local alarm without the WAN. And it reports its own health upstream, so a silent gateway shows up as a fault rather than as an absence of alerts.

Centrally: features and reduced telemetry land alongside asset master data and maintenance history. Training, fleet comparison, benchmarking and drift monitoring run here, because they need the population. Alert handling and routing run here, and critically the alert becomes a work order in the maintenance system of record rather than an email. Dashboards and reporting are served here, as is the management plane governing model versions, configuration and certificates across the fleet.

The two decisions that vary most are how much inference sits locally and how deep the local retention window is, both driven by autonomy. A well-connected urban facility can run a thin gateway; an offshore installation needs a far more capable local node. Same architecture, different weighting.

8. What an edge deployment actually costs you

This is the part consistently underestimated in business cases. The cost is not the hardware, which is the cheap, one-off, easy-to-approve component. The cost is that you have created a permanent distributed computing estate, and it behaves like one.

Consider what you now own: a population of computers in plant rooms, risers, substations and outdoor enclosures, which is to say in dust, heat, humidity, vibration and variable power quality, the conditions computers like least. Each has an operating system to patch, a runtime to update, certificates that expire, storage that fills and eventually fails, and a clock that drifts. Each runs software, models included, with versions to track and occasionally roll back. And each can fail silently, which is worse than failing loudly, because a monitoring device that stops reporting looks exactly like an asset that has stopped misbehaving.

Then consider what is hard at distribution: patching a fleet on a plant network with restricted outbound access; testing an update before it reaches a hundred sites that are not identical; recovering a gateway that failed to boot after an update, three hours away, behind a locked door needing a permit and an escort. None of it is exotic. It is the standard obligation of distributed infrastructure, and it arrives the day you deploy the first gateway.

The practical implication is a design bias: put the minimum at the edge that the five forces genuinely require. Bandwidth is an operating cost you can forecast and negotiate. An unmaintained gateway estate is a risk you cannot.

9. The OT and IT ownership question, which is why projects stall

The usual reason these deployments stall is not technical. It is that nobody can agree who owns the thing in the middle. The gateway sits on the boundary between operational technology and enterprise IT, and both sides hold reasonable positions that are incompatible in practice.

The OT view: this device is on my plant network, wired to my instruments and possibly adjacent to control systems, so nothing is patched without a change window and nobody touches it without a permit. My priority is availability and safety, and my change cycle is measured in scheduled outages. The IT view: this is a general-purpose computer with an operating system and a path to a cloud platform, therefore it is inside my security perimeter and subject to my patching, hardening and asset-management standards. My priority is confidentiality and integrity, and my patch cycle is measured in weeks.

Both are right, and without an explicit agreement the result is a device patched by nobody, monitored by nobody and, when it fails, escalated to nobody. I have seen this produce gateways running unpatched for years with default credentials, not through negligence but because ownership was never assigned.

Resolve it before any hardware is ordered, with a written division of responsibility covering at minimum: who owns the device asset record; who authorises and who performs patching; who owns model and application deployment; who monitors device health and is alerted when a node goes silent; who holds credentials and rotates them; what the change-control path is and how it meets plant change control; who is called when a node fails; and who funds the hardware refresh. Without that document the project has an unresolved dependency regardless of how good the architecture is. It is an organisational deliverable, and usually the critical path.

10. Gateway and protocol translation realities

• Protocol coverage is never as complete as the datasheet implies. A gateway that supports a protocol family may not support the profile, register layout or vendor extension your equipment uses. Verify against the devices on site, not the product page. The primers on OPC UA, Modbus and MQTT are worth reading before you specify anything.
• Polling costs the device being polled. Older controllers have finite capacity to answer requests, and an over-enthusiastic poll can degrade the control function you are supposed to be observing. Agree the regime with whoever owns the controller, and prefer subscription or report-by-exception where supported.
• Tag naming and semantics are the real work. Establishing what each point means, which asset it belongs to, in what unit, with what quality flag, and mapping that to the asset register, is where the effort goes. A gateway forwarding ten thousand anonymous tags has moved the problem, not solved it.
• Connection direction matters. Outbound-initiated connections from the gateway are far easier to get approved than inbound paths into the plant network, and that shapes how remote management works.
• Time is harder than it looks. Synchronised timestamping at the point of acquisition is what makes cross-asset and cross-site correlation possible. Clock drift quietly corrupts everything downstream and is tedious to detect after the fact.

11. Store-and-forward: what must survive a link outage

Store-and-forward is usually treated as a checkbox, and it deserves a design conversation, because the questions it raises expose whether the rest of the architecture has been thought through.

Start with the outage you are designing for: not the average one, the one you would find unacceptable to lose data through. That figure, with the onward data rate, sets the local storage you need, and it is worth calculating rather than accepting a default. Then decide what happens when the buffer fills anyway, because eventually it will. Overwriting the oldest data is usually right for continuous trend telemetry; preserving the oldest and refusing new data almost never is; degrading gracefully by reducing sampling rate or keeping features while dropping raw data is often best. Some categories should never be dropped at all: alarm events, threshold crossings and anything with a compliance character deserve a small prioritised queue not competing with bulk telemetry for space.

Replay needs attention too. When the link returns, a fleet all flushing at once can saturate the link that just recovered and overwhelm central ingestion, so staggered rate-limited replay is the civilised behaviour. Ordering and idempotency matter as well: data arriving out of sequence or duplicated during replay produces trend artefacts that look exactly like equipment faults.

Finally, decide what the site can do while disconnected. If operators need current condition and alarms during an outage, that means local visualisation and local alerting, a meaningful addition to edge scope. If they do not, say so explicitly and keep the node thinner. The mistake is leaving it unstated and discovering the requirement during the first real outage.

12. Security at the edge

An edge node changes your security posture in ways a central deployment does not, and four aspects need explicit treatment.

Physical access. A gateway in a plant room, riser or roadside cabinet is reachable by contractors, cleaners, other trades and occasionally the public. That means enclosure security, port protection, encryption at rest where the data warrants it, and an assumption that the device may be tampered with or removed. Credentials acceptable in a locked rack are not acceptable in a shared plant room.

Patching. An edge fleet is an attack surface that grows with node count and is only as secure as its patch cadence. This is where the ownership question becomes a security issue rather than an operational one. An unowned fleet is an unpatched fleet.

Credentials and certificates. Each node needs a unique identity, not a shared one, so a single compromised device can be revoked without re-provisioning the estate. A fleet-wide certificate expiry that nobody tracked will take monitoring offline in a way that is confusing to diagnose. Rotation belongs on a calendar with an owner.

Segmentation. A device bridging the plant network and an external platform is exactly the path an attacker wants, so it belongs in its own segment with tightly constrained flows in both directions and no routing role it does not need. The principles are the same ones that apply to any connected building or plant system, and the BMS cybersecurity guide covers segmentation and remote access in more depth than is worth repeating here. For the governance frame, the NIST and ISO material on industrial and information security is what your security team will already recognise.

13. MLOps at the edge and knowing when a model has gone stale

If you place inference at the edge, you have accepted a distributed machine learning operations problem, and it is harder than the central equivalent in three ways.

Deployment and versioning. You need to know at any moment which model version runs on which node, roll a new version out progressively, roll it back when it misbehaves, and handle the node that was offline during a rollout and returns running something old. Ordinary release engineering, applied to devices you cannot always reach.

Drift detection. A model trained on one period of operation becomes less appropriate as the asset ages, the duty changes or an instrument is replaced. Centrally, drift is visible because you hold the data. At the edge, if the node ships only alerts, you are blind: a model that has silently stopped detecting anything looks identical to a healthy asset population, which is the most dangerous failure mode in the architecture. The mitigation is to make the edge report enough to be evaluated centrally, meaning the features it computed, the scores it produced, the distribution of those scores over time, and its own health. Send the evidence, not just the conclusions. The bandwidth cost is modest against raw data and it is what makes a remote model auditable.

Feedback from outcomes. The signal that tells you whether a model is any good is what the technician found on arrival, and that closure data lives centrally in the maintenance system. Every prediction needs to be traceable to the work order it raised and the finding recorded against it, so alerts can be classified as genuine, nuisance or missed. Without that loop you cannot measure precision, cannot retrain on labelled outcomes, and cannot defend the program when someone asks whether it works.

14. A decision framework you can apply function by function

The sequence I would run for a new deployment. It takes a workshop, not a project phase.

• List the functions. Start with the ten above. Do not proceed with a diagram that does not name them individually.
• Characterise the data at source. Per measurement type: sampling rate, resulting raw volume, and what fraction carries diagnostic meaning. High-frequency signals should be planned separately from periodic readings.
• Establish the connectivity reality, site by site. Not the design intent: bandwidth actually available, whether it is metered, who shares it, and the honest outage history. One architecture across very different sites is usually a mistake.
• Define the autonomy requirement. What must keep working during that outage, and what is acceptable to lose? This answer drives more of the design than anything else.
• Confirm the data constraints in writing. Ask what specifically cannot leave, and whether derived features and health scores are in scope. Do not design around an assumed constraint.
• Test the latency claim. Apply the one-minute test to every function proposed for the edge on latency grounds, then find the real reason or move it centrally.
• Place each function and record the reason. The reason matters more than the placement, because it is what lets you revisit the decision when connectivity or the fleet changes.
• Cost the edge estate over its life, not its purchase. Hardware, installation, patching, monitoring, certificates, spares, refresh and the owner's time, against the bandwidth cost of a thinner edge.
• Settle ownership before ordering hardware. The OT and IT division of responsibility, written down. Treat it as a gate.
• Design the observability of the edge itself. Node health, model version, feature and score reporting, silent-node detection. If you cannot see the edge from the centre, you do not have an architecture, you have a set of appliances.

The first seven steps are an afternoon with the right people in the room. The last three are where projects either become real or quietly reveal that they are not funded, and I would rather discover that before the hardware arrives.

The idea to walk away with

Edge and cloud are not alternatives. They are two places to put each of about ten functions, and a defensible architecture places each one for a stated reason. Acquisition, protocol translation and buffering are always local; training, fleet comparison, long-term history and visualisation are always central; and the open questions are filtering, feature extraction, inference and local alerting, decided by data volume at source, bandwidth, autonomy and residency, in roughly that order. Latency, the reason most often given, is almost never the reason.

And whatever you place at the edge, cost it honestly. That burden is manageable when named, owned and funded, and corrosive when assumed away, because the failure mode is not a dramatic outage, it is a monitoring estate that quietly stops being monitored.

Final thoughts

The best conversations I have had on this were the ones where nobody used the phrase "edge versus cloud". They worked through the functions, established the connectivity and autonomy facts, argued about four genuinely open placements, wrote down the reasons, and then spent more time on who would patch the gateways than on where inference would run. That is the right allocation of attention: the placement decisions are tractable engineering, and the ownership questions are where these deployments succeed or stall. So resist the architecture diagram for one more meeting. Build the placement table first, with a reason against every row, then cost the edge estate over its full life with a named owner attached.

Related reading: Predictive maintenance: a practitioner's guide, Condition monitoring techniques, IoT sensors for predictive maintenance, SCADA and historian integration, OPC UA explained, BMS cybersecurity for connected buildings.