Why buildings will never become fully autonomous through traditional BMS and EMS?

From a purely technical standpoint, it is entirely possible to connect Building Management Systems (BMS), smart meters, Energy Management Systems (EMS), and Programmable Logic Controllers (PLCs) through physical gateways, stream that telemetry to a centralized cloud environment, run machine learning models on aggregated, high-dimensional time-series datasets, compute optimization actions sequentially, and send control commands back down to the building systems. Theoretically, these centralized layers should integrate multiple legacy software systems into a single platform. Instead, the current reality presents distinct, fragmented software for each individual energy system. While reliable on their own, these siloed applications are not economically rational or operationally viable for complex properties, given the real-world volatility of scheduling, control settings, and continuous internet connectivity.

But should we honestly allow critical infrastructure to be controlled entirely in the cloud through BEMS? Is it sufficiently reliable and safe? What happens if we overheat spaces or damage capital equipment by constantly fluctuating setpoints? For the majority of commercial, industrial, and institutional sites, the answer is a definitive NO!

Latency and jitter break automation for closed-loop systems

Physical systems are highly sensitive to both delay and variability. When a control loop is extended over a wide area network, two major technical degradation mechanisms emerge:

Phase lag (latency): cloud round‑trip latency for industrial IoT workloads commonly sits between 50 and 500 milliseconds (ms). This delay introduces artificial process dead time into the system e.g. valve adjustments, chiller modulation, or fan speeds delays forces the controller to react to a physical state that has already shifted. 

Variable network latency (jitter): In commercial HVAC and process automation setups, when the communication path varies unpredictably due to public internet congestion, safety margins shrink and the system risks entering destructive process oscillations. 

Drawing the architectural line between cloud and edge

To design a resilient building architecture, specialists must separate tasks by their tolerance for latency, jitter, and network failure. Evaluating options for automated building operations requires an objective comparison of the three primary structural pathways available.

Cloud-Only: It is perfectly suited for high-level, open-loop processing where data delays carry no operational or physical risk. These workloads involve human-in-the-loop validation or slow-moving macro adjustments e.g. Aggregating monthly consumption across 50 properties to track Scope 2 emissions indicators, or pushing static seasonal calendar updates to a BMS weeks before a seasonal shift occurs. Cloud-only autonomy operates under the assumption that the external network link is persistent. However, real-world building operations introduce several challenges such as operational failure or drop-backs during network outages, cloud data center availability incidents, firewall configuration errors, security policy updates or port blocks during routine IT maintenance, and cybersecurity attack surface.

Edge Only: When software acts directly on hardware without human intervention, network dependency introduces immediate physical and financial risk. That means when the internet link fails, a cloud‑hosted controller cannot read sensors or send commands. If the last command left a valve, damper, or heater in an aggressive state, the system can drift into unsafe or inefficient operation. These workloads require real-time, deterministic local loop responses.  The example includes modulating heat pumps or cooling plants in direct response to immediate spikes in electrical current or spot prices, or airflow regulation based on volatile CO2 and temperature readings.  Moving execution to the edge removes the WAN completely from the active control path. Edge autonomy keeps the core sensing, reasoning, and acting sequence physically inside the building envelope, rendering cloud connectivity completely optional for real-time survival. However, it may imposes local hardware compute constraints if not engineered correctly, increases the complexity of cross-site coordination, and requires specialized deployment procedures for long-term software lifecycle updates. For commercial, corporate, and industrial assets categorized as critical infrastructure, a cloud-only control model introduces severe structural vulnerabilities. Data residency, operational privacy, and security mandates under European frameworks become difficult to guarantee when physical control paths are dependent on systems outside local legal boundaries.

Hybrid autonomy: Edge keeps safety-critical control logic on-premises, while offloads intensive historical machine learning training and portfolio-wide benchmarking to a centralized European private cloud for non-time-critical processing, aggregation, and macro-optimization without exposing the local hardware loop to external network vectors. This approach ensure latency becomes deterministic, and eliminate network-induced process oscillations. However, this setup requires a highly resilient orchestration framework and demands explicit engineering definitions regarding exactly which workloads execute locally versus which sit in the cloud. 

Traditional building systems fall short

Building Management Systems (BMS) were fundamentally architected for static monitoring, basic scheduling, primitive threshold alarms, and rigid, rule-based local control loops. These automation setups typically process variables using polling intervals measured in seconds to minutes. While this configuration is functional for basic supervisory oversight, it lacks the long-period historic data and resolution required for highly complex, continuous thermodynamic optimization. Furthermore, because most legacy HVAC systems are reactive, they are designed to run based on maximum occupancy conditions, which frequently leads to overcompensated, inefficient operations.

In contrast, traditional Energy Management Systems (EMS) were primarily architected for retroactive accounting and compliance reporting. These legacy platforms typically rely on low-resolution smart meter data or aggregated inputs, such as monthly utility bills, to generate historical consumption reports, track sustainability KPIs, and alert facility managers to macroscopic billing anomalies. They excel at identifying that an energy spike occurred during a previous billing cycle, but their native data structures completely lack the spot-price visibility or granular, predictive, high-frequency telemetry needed to diagnose why it occurred—or to intervene programmatically before it happens.

The challenge becomes even more pronounced as renewables, batteries, EV charging infrastructure, and electric heat pumps are introduced. Each of these assets comes with its own proprietary software, and they often do not talk to each other at the overall building level. Ultimately, neither system possesses the infrastructure required for modern, autonomous building orchestration. This decoupled architecture of BMS, EMS, and siloed asset software creates a critical operational gap, resulting in a highly time-consuming process for facility managers and energy specialists.

True operational autonomy requires an architecture capable of sensing environmental metrics, processing multi-variable inputs, and executing precise structural actions locally at the exact timescale of the physical process itself, governed by hard safety boundaries and fail-safe behaviors hardcoded on-site.

Curious to learn how your building can solve this paradox? Discover LEO, our purpose-built Agentic AI designed to run on-site with edge device (such as an Apple Mac Mini or Nvidia Jetson Nano) or within your secure private cloud. Connect with the Preflet team here→