Edge or cloud for building automation

A building automation system makes the edge-versus-cloud decision whether anyone writes it down or not. A thermostat reading, a door-access swipe, a chiller's return temperature: each signal is processed somewhere, either a controller on the sensor's own local network, or a server reached over the building's internet connection. Most systems installed in the last decade do both, splitting functions between an on-site controller and a vendor's cloud platform, rarely as a deliberate choice. It is usually just whatever the product ships with.

Four questions force the decision back open once installation ends. What has to keep the chillers and the lighting running when the internet fails. How much delay a control loop can tolerate before an occupant notices. Which country a log of who opened which door is legally permitted to sit in. And how a fleet of controllers gets a security patch five years after the installer has moved on. Each has a documented answer somewhere. No single answer fits every building.

What runs at the edge, and what runs in the cloud

Edge means the controller physically present in the building, wired or radio-linked to the point it reads or actuates. Cloud means a server reached over the internet, run by the platform vendor. Tridium's Niagara framework, used across a large share of commercial building automation, names the split directly. A Niagara Supervisor performs analytics, centralised data logging, archiving, alarming, dashboarding and master scheduling, while field-level JACE controllers handle the points themselves, wired to the sensors and actuators on the floor they occupy. Tridium's own product pages describe the trend as pushing field-level work down to the JACE rather than up to the Supervisor.

What has to survive a dead internet connection

BACnet, the protocol ASHRAE's Standard Project Committee 135P began developing in 1987 and ANSI approved as a national standard in December 1995, is listed on ASHRAE's own bookstore, as of September 2026, as ANSI/ASHRAE Standard 135-2020. Its Change of Value reporting service lets a device subscribe to receive reports of a property's value changes, pushed to it the moment they happen rather than polled for. At BACnet's first public demonstration, an ASHRAE exposition in February 1996, participants showed peer-to-peer controller communication between products from different vendors. None of it needs the internet. A BACnet panel keeps closing its loops through whatever takes the site's internet down for a day.

Matter, the newer standard for consumer and light commercial devices, makes a similar commitment in plainer language. The Connectivity Standards Alliance's own FAQ states that Matter is a local connectivity technology, and that a Matter-only device needs an internet-connected controller in the building only to allow control from away from home, not to operate locally. A manufacturer can add cloud connectivity for extra features. The standard does not require it.

Cloud platforms expect the connection to drop

The two dominant industrial cloud platforms treat an offline period as a design case, not an edge case. Microsoft states that once an Azure IoT Edge device has synced with IoT Hub once, it can keep working with intermittent or no connection indefinitely; a local hub module stores outbound messages until the link returns. The defaults matter: an undelivered message expires after a time-to-live setting that defaults to 7,200 seconds, two hours, unless raised, and a device's status can sit at 200 OK in the Azure portal for the whole outage, because the agent reporting it cannot phone home to say otherwise.

AWS makes an equivalent promise for its own edge runtime. Its FAQ states that AWS IoT Greengrass lets devices keep data in sync and communicate securely, even when not connected to the internet. The point of running logic on the device rather than the server, AWS's own documentation says, is to let it collect and analyse data closer to where it is generated and react autonomously to local events.

Latency is a round trip, and the round trip is the point

A cloud round trip adds the leg out to the internet and the leg back, on top of whatever the local network already takes. Both major cloud vendors give that as the reason to run logic locally, in their own documentation rather than a sales deck. BACnet's Change of Value mechanism does the same job at protocol level: a controller announces a change itself, instead of a remote system polling for it. None of this makes a cloud path unusably slow; a well-provisioned connection returns most commands in well under a second. What changes is the variance, since a round trip depends on a link the contractor does not control. A loop with a genuinely short deadline, a fire damper, a cleanroom's pressure differential, does better on hardware that never leaves the building to decide.

Where the data is allowed to sit

Building automation data is not always as anonymous as it looks. An access log tied to a badge number counts as personal data once joined to an identity, and so does an occupancy trace that lines up with when a named tenant is home. Moving that kind of data out of the jurisdiction where it was collected can trigger a specific legal test. In the Dubai International Financial Centre, DIFC Law No. 5 of 2020 sets that test out in Article 26.

Where no adequacy finding exists, Article 27 allows the transfer if the controller has put appropriate safeguards in place, among them standard data protection clauses adopted by the Commissioner of Data Protection, or if a specific derogation applies, such as the data subject's informed consent. A cloud region chosen on hosting cost alone, without checking which route applies, is a decision made by whoever configured the account rather than whoever is legally responsible for it.

Firmware: the update mechanism is a spec, not an afterthought

The US National Institute of Standards and Technology sets out what a defensible update mechanism looks like in NISTIR 8259A, its IoT Device Cybersecurity Capability Core Baseline.

NIST lists five elements under that baseline: update through remote or local means, verify and authenticate an update before it installs, let an authorised entity roll software back to a previous version, restrict updating to authorised entities, and let an authorised entity enable or disable updating. A platform that cannot answer yes on rollback asks for blind trust. Every patch becomes a one-way door.

AWS IoT Greengrass builds rollback in as the default. Its documented failure handling policy defaults to ROLLBACK: if a deployment fails, the platform rolls the device back to its previous configuration automatically. That is one vendor's answer, not the only one; the industrial standard IEC 62443-4-2 covers similar ground under the heading Technical security requirements for IACS components, though its update clauses sit behind IEC's paywall.

A sensible split

Almost nothing sold as building automation is purely one or the other. The useful question is which side of the split a given function sits on, and why.

• A control loop that has to close within the building, an HVAC setpoint, a lighting scene, a door's access decision, stays on a controller already shown to run with the link disconnected, not one whose offline behaviour is assumed.
• Anything that only matters across time or sites, trend graphs, portfolio dashboards, energy benchmarking, can live in the cloud, since none of it needs an answer within the second.
• Firmware distribution belongs in the cloud, but the update mechanism has to satisfy the NIST baseline above before a fleet of controllers is exposed to it, not after the first bad update.

Before signing off a system, ask the integrator to unplug the internet connection in the room and show what still works. That test settles the edge-versus-cloud question faster than any architecture diagram.