How Much Software Belongs at the Industrial Edge?

An industrial asset sends a temperature reading. Another follows a few seconds later. Then the connection drops.

Twenty minutes later, the gateway reconnects and uploads the measurements it stored during the outage. Some of those measurements describe events that happened before data the platform has already received from other sources. The platform now has to place the delayed telemetry into the right sequence and still show the asset’s current state.

Where should that logic run?

Putting it on the gateway looks attractive. The data is already there, the gateway knows about the connection failure, and local processing avoids another dependency on the network. But now the gateway owns part of the asset state. It needs enough persistence to survive a restart, rules for delayed data, and a way to reconcile its view with the backend after reconnection.

We usually start an edge architecture discussion with failure behavior. What must keep working when this node loses everything around it, and what state does it need to do that correctly? From there, we can decide which functions need local autonomy and only then size the compute they require.

We have tried the platform approach before

There is some history here.

Microsoft released Windows 10 IoT Core in 2015 as an OS for small, connected devices. Samsung announced ARTIK the same year, combining production modules, software, development tools, security and cloud connectivity. Intel’s push included Edison, Galileo and later Joule alongside its broader IoT platform work.

The ambition was larger than connecting a sensor to MQTT. These ecosystems were trying to give developers a reasonably standard foundation for building and managing connected products.

The individual bets aged differently. Intel discontinued Edison, Galileo and Joule in 2017. Microsoft retired Windows 10 IoT Core in 2020 while continuing its industrial IoT line through IoT Core Services and Windows IoT Enterprise. Samsung’s ARTIK hardware and cloud offering also left the market.

ARM-based processors and MCUs, low-power connectivity and much smaller embedded devices ended up taking a large part of the IoT market in another direction. At the same time, the heavier end of IoT moved toward gateways, industrial PCs and cloud-managed fleets rather than one common device-to-cloud platform. The result is a much wider range of places where software can run between the sensor and the backend.

Emerson’s PACEdge 3.0, released in August 2026, is a good example. It combines industrial data aggregation with containerized applications for analytics, visualization, vision and AI/ML. It also supports group-based device management and deployment of applications, security updates and OS updates. Emerson PACEdge 3.0 announcement

We can do much more at the edge now. That makes being selective more important.

Who owns the state?

One of our industrial IoT projects modeled roughly 105,000 physical assets and processed about 5.5 million sensor measurements and 750,000 operational events per month.

The numbers were substantial, although scale wasn’t the nastiest part of the system. Telemetry came from heterogeneous sources, sometimes late and out of order. Connectivity failures produced bursts of buffered measurements. The platform had to reconstruct a near-real-time asset state from data whose arrival sequence could differ from the sequence of events in the field.

First-generation architecture had reached its scalability limits. In the second generation, we separated ingestion, processing and consumption, redesigned the data model and kept the field communication concerns at the gateway layer. The gateway could isolate protocols and cope with intermittent connectivity without becoming the place where every piece of asset state had to be resolved.

There is an architectural temptation here: if the gateway already buffers the measurements, why not calculate more there?

Sometimes we would. A control decision that has to survive a network outage belongs close enough to the equipment to survive that outage. Local filtering can make sense when bandwidth is constrained. Protocol handling obviously benefits from staying near the field interfaces.

Current asset state is different when its calculation depends on information beyond one gateway’s view.

Take the delayed batch from the opening. The backend may have processed newer information before that batch arrives. If the gateway has also been maintaining its own state, reconnection becomes a synchronization problem between two systems that both have legitimate information about the same asset.

We’ve gained local autonomy and bought ourselves another distributed state problem.

How we decide what stays local

Start with the outage

We start by asking how long the function has to keep working without the upstream system. A control loop with a millisecond response requirement answers that quickly. If a monitoring function can tolerate an interruption and catch up after reconnection, giving the gateway its own authoritative state needs a stronger justification.

The outage duration matters too. Keeping a function alive for thirty seconds while the connection is recovering is a different design problem from running independently for eight hours. Longer autonomy means thinking about what state accumulates locally, how much history the function needs and what happens if the gateway itself restarts during that period.

Check what the gateway actually knows

Local authority works best when the node has enough information to make the decision correctly. A controller operating from directly connected sensors may have everything it needs. An asset-monitoring gateway may see only one part of a much larger picture.

Our telemetry platform is a good example. Current asset state could depend on measurements and operational events arriving through different paths. A gateway could have perfectly valid local information and still lack events the backend had already received elsewhere.

Putting state authority on that gateway would require either bringing more context down to it or accepting divergence during disconnection. Both approaches are possible. We want a reason to pay for them.

Design reconnection before deployment

This is the part we would settle while drawing the architecture, rather than after the first field outage. State needed through a gateway restart has to be persisted locally, with an explicit validity period where stale data can affect decisions. Reconnection also needs a defined recovery path. Depending on the system, the backend may replay buffered events, reconcile a state snapshot or resolve conflicts between changes made on both sides.

The recovery mechanism is part of the cost of moving authority to the edge. If a local function requires substantial synchronization machinery simply to return to a consistent state after an expected outage, we will reconsider how much authority it needs.

Our preference is to give edge software enough state and authority to keep the required function working through the failures it is expected to survive. We don’t move additional state there simply because the gateway has enough memory and compute to maintain another copy.

Command delivery is a good way to expose weak boundaries

In August 2026, AWS published “Mechanisms for IoT commands, control, and configuration”, comparing Direct Messaging, MQTT Pub-Sub, Commands, Device Shadows and Jobs. They have different behaviors around delivery, execution tracking, persistent state and fleet operations.

Consider a configuration change sent to an industrial device. Direct Messaging can tell the application that an online device acknowledged the message. If the connection fails while the device is applying the configuration, that acknowledgement has already outlived its usefulness. The system needs to know what configuration the device ended up running.

AWS Commands adds execution state and history for that kind of workflow. Device Shadows address another version of the problem by keeping desired and reported state. Jobs extend the problem across a fleet, where rollout rate, retries, timeouts and abort criteria start to matter.

We find this a useful way to think about edge architecture in general: draw the failure first.

Disconnect the gateway halfway through the operation. Restart it with buffered data on disk. Leave it offline during an update rollout. Then reconnect it after the backend has moved on.

The software that still must behave correctly under those conditions has a strong claim to the state and logic it needs locally. Everything else deserves another look before it gets added to the field stack.

This is also where our article on Hardware-in-the-Loop testing for Edge, IoT & MedTech devices becomes relevant: the failure behavior we are using to draw the architecture boundary eventually must be reproduced and tested against real interfaces and hardware.

AI makes the boundary easier to get wrong

AI inference has brought the compute question back to the foreground because current edge hardware can run workloads that would have been unrealistic on an industrial gateway a decade ago.

There are applications where local inference is an easy architectural call. Our Edge AI Drone for Orchard Monitoring is one: the system processes imagery in flight, with no cloud fallback. A vision pipeline can generate enough data to make continuous upstream transmission unattractive, and some detection or control paths have latency requirements that leave little room for a remote service.

We would still size the decision against the real gateway workload.

The telemetry gateway from our earlier example has very different resource behavior during normal operation and after a long connection outage. Once the link returns, it has buffered data to drain while normal traffic continues. Add inference to the same node, and model qualification needs to cover that operating condition too, rather than a clean benchmark with an idle gateway.

The same applies over the product lifetime. Models change, runtimes change, security components grow, and someone finds another useful container to deploy. The CPU and memory soldered into the industrial computer are less enthusiastic about roadmap expansion.

This is where “edge AI” stops being a category and becomes ordinary systems engineering. We care about worst-case load, failure recovery, update paths, resource contention and what happens when one workload misbehaves next to another.

The gateway from the opening will lose its connection again. When it does, the useful architecture is the one where we already know which functions continue locally, which state they own, and how the rest of the system catches up afterwards.

That is how we decide how much software belongs at the industrial edge.