The decision about where industrial and facility data should live comes down to a single sorting rule: anything a control loop depends on stays at the edge, and anything that only has value when compared across time or across buildings belongs centrally. Latency decides the first category. Context decides the second. Most disagreements about edge versus cloud are really disagreements about which category a given data stream falls into.
The question reaches architects and facility designers earlier than it used to. A building’s mechanical systems, its metering, its access control, and its production equipment now generate continuous data, and where that data is processed shapes the network infrastructure, the equipment rooms, and the service contracts that follow the building into operation. Deciding it late means retrofitting decisions that should have been drawn.
What the split actually is
Edge computing places processing near the source rather than sending everything to a remote data center. Research on edge-native applications describes the pressure driving this, observing that the convergence of 5G wireless networks and edge computing enables applications that are simultaneously bandwidth-hungry, latency-sensitive, and compute-intensive. The same work sets out a three-tier arrangement, with resources orchestrated across the cloud, intermediate cloudlets, and the device itself.
In a plant or a large building, those tiers map onto physical things. The device tier is the controller in the mechanical room. The intermediate tier is a local server or gateway on site. The cloud tier is wherever the historical record and the cross-portfolio analysis live. Each tier has a different tolerance for delay and a different appetite for storage.
The mistake worth avoiding is treating this as a binary. Almost no serious installation puts everything in one place. The design question is which specific functions sit where, and that question has answers rather than opinions.
Latency is the first sorting rule
A control loop that has to respond in milliseconds cannot wait for a round trip to a remote data center. Safety interlocks, compressor sequencing, and anything that trips equipment belong physically close to the equipment, and they belong there regardless of how good the network is, because the network is a dependency that can fail.
Standards bodies have started codifying what the local tier is responsible for. IEEE 2805.2-2025, the standard for data acquisition, filtering, and buffering protocols for edge computing nodes, specifies protocols for buffering, filtering, and pre-processing data collected from shop-floor industrial controllers including programmable logic controllers, microcontrollers, and industrial robots, with data from field devices stored, filtered, and pre-processed according to reconfigurable rules.
Reference explanations of industrial IIoT describe the same flow as four layers, moving from sensing through the edge and a transport layer up to applications, and the boundaries between those layers are exactly where the edge-or-cloud decision gets made in practice. What sits below the transport layer keeps working when connectivity drops. What sits above it does not.
That framing gives designers a usable test. For each data stream, ask what breaks if the internet connection fails for four hours. Anything on the list of things that break needs to be handled locally. Anything not on the list is a candidate for central processing, and centralizing it usually makes it more useful.
| The competing demands
Research on edge-native applications describes them as simultaneously bandwidth-hungry, latency-sensitive, and compute-intensive, requiring network-aware and load-aware orchestration of resources across the cloud, intermediate cloudlets, and the device tier. |
Bandwidth, data gravity, and what never needs to leave
The second sorting rule is volume. A vibration sensor sampling at high frequency generates far more data than any site connection wants to carry continuously, and almost none of it is interesting. What matters is the deviation, not the twelve hours of normal readings surrounding it. Filtering at the edge and forwarding the summary is not a compromise; it is the correct design.
There is a second reason to filter early that has nothing to do with cost. Raw high-frequency data ages badly. Nobody returns to it, nobody can interpret it years later without the context that produced it, and storing it creates an obligation to secure and eventually dispose of it. A well-designed edge layer decides what is worth remembering at the moment the data is generated, when the context is still available, rather than deferring that judgment to whoever inherits the archive.
Data gravity works in the other direction. Once years of operating history accumulate centrally, new analysis wants to happen where the history already is, because moving the history is expensive and moving the query is cheap. This is why the long-term record tends to consolidate even in installations that keep aggressive local processing. The two forces are not in conflict as long as the boundary between them is deliberate.
For a building at design stage, this translates into concrete provisions: local compute and storage sized for the fast loops, a network path sized for summaries rather than raw streams, and enough physical space and power in the equipment room for hardware that did not exist in the original mechanical schedule.
The interoperability problem nobody budgets for
The harder constraint is semantic rather than technical. Two identical chillers from different manufacturers will report the same measurement under different names, in different units, with different conventions about what counts as a fault. Collecting both streams is easy. Comparing them requires someone to establish that these two differently named values describe the same physical thing.
This is the problem industrial information models exist to solve. The OPC Foundation describes its companion specifications for OPC UA information models as enabling interoperability at the semantic level, and notes that the protocol was designed for scalability across application domains ranging from field-level devices for measurement or identification and programmable logic controllers up to enterprise management support.
The scale of the effort is easy to underestimate from a drawing. A mid-sized industrial facility can carry several thousand individually named points, arriving from equipment supplied by a dozen manufacturers across three decades of construction. Mapping those into a shared model is not a task an integrator finishes during commissioning week, and it is not a task that stays finished, because every subsequent equipment replacement adds new names that have to be mapped again.
In a single building, this work can be skipped by having one person remember the mappings. Across a portfolio it cannot. The translation layer is the part of a connected facility program that consumes the most effort and receives the least attention in the business case, and skipping it is the most common reason a second building takes as long to connect as the first.
Buildings are converging on the same answer
Public sector portfolios have been working through this at scale. The U.S. General Services Administration’s smart buildings directive, issued in 2021, defines the objective as the convergence of a building’s management, monitoring, and control systems onto common supported network infrastructure, enabling access to real-time control system performance data toward the goal of interoperability for enhanced operations, cost savings, and optimal building environments.
The phrasing repays attention. Convergence onto common infrastructure, with interoperability named as the goal rather than assumed as a byproduct. That is the same conclusion the industrial side reached from a different direction: the value of connected systems shows up only after the systems agree on what they are describing.
For anyone specifying a facility now, the practical version is short. Keep the fast loops local and make them survive a network outage. Filter aggressively before transmitting. Consolidate the long record centrally where comparison is possible. And write the naming and modeling work into the scope explicitly, because it will happen either way, and it is far cheaper as a design decision than as a discovery during commissioning.
