Edge, Cloud & Gateways

Cloud computing means sending data off-site to large, shared data centres - effectively limitless storage, powerful processors, heavy analytics and machine-learning models, all managed for you and reachable from anywhere. It is where big historians, cross-portfolio analytics and elaborate digital twins comfortably live, because you can rent as much compute and memory as you need.

Edge computing means doing the work on or near the building itself, on local devices - gateways, edge servers, smart controllers - close to where the data is born. Instead of shipping every raw reading away, the edge can filter, aggregate, run control logic and react locally, in milliseconds, without a round-trip to a distant data centre.

Neither is simply better. The cloud gives you scale, durability and advanced analytics but adds distance - latency, dependence on your internet link, ongoing bandwidth and subscription cost, and the privacy questions of data leaving the premises. The edge gives you speed, autonomy and data minimisation but is constrained in compute, memory and manageability. The real art of building-data architecture is deciding, job by job, which work belongs where - and the next sections give you the criteria.

It helps to picture a continuum rather than two boxes. At one end sits the device itself, which can do a little processing; next the on-site gateway or edge server; then perhaps a regional server; and finally the cloud. Work can land anywhere along that line, and often the same data is handled at several points - filtered at the edge, summarised at a gateway, analysed in the cloud. This spread-out arrangement is sometimes called fog computing, and it is the shape most serious building systems actually take.

Five factors govern where a given job should run.

Latency. Anything needing an instant response - a control loop, a safety interlock, occupancy-driven lighting - should run at the edge, because a cloud round-trip of even a fraction of a second is too slow and too dependent on a healthy link. Slow analytics - daily energy trends, benchmarking - are happy in the cloud.

Resilience. If the internet drops, an edge system keeps controlling the building; a cloud-only system may go blind or dumb. Critical control should never hang on an external connection, so it belongs at the edge (or in the BMS).

Bandwidth and cost. Streaming every raw reading to the cloud is expensive and often wasteful. The edge can aggregate and filter - send a summary, or only exceptions - cutting both bandwidth and cloud cost dramatically.

Privacy and security. Some data is sensitive - camera feeds, occupancy that reveals individual behaviour. Processing it at the edge and sending only anonymised results keeps raw personal data on-site, reducing exposure. Connected buildings carry real cyber and privacy risk; treat statutory and security sign-off as work for qualified professionals.

Scale and advanced analytics. Training machine-learning models, storing years of history, comparing a whole portfolio - these want the cloud's near-limitless resources. The pattern that falls out is clear: fast, critical, sensitive, high-volume work at the edge; heavy, historical, cross-site intelligence in the cloud.

There is also a cost dimension that is easy to overlook. Cloud services usually charge for ingest, storage and egress, so a building that naively streams every raw reading can run up a surprising monthly bill for data it never looks at. Doing the reduction at the edge - averaging, thresholding, sending only changes or exceptions - is often the single biggest lever on both bandwidth and running cost. The edge is not just faster; frequently it is cheaper, precisely because it lets you send less.

The device that makes the edge real is the gateway - the workhorse on the boundary between the building and the wider network, and the connective tissue of this whole module. A building or IoT gateway does several jobs at once.

It is a translator: as we saw with protocols, it converts BACnet, Modbus, KNX, LoRaWAN and Zigbee into a common form - very often normalising everything into MQTT/JSON for the platform and twin, so the messy multi-protocol reality below becomes one clean stream above.

It is a buffer: when the internet link drops - and it will - a good gateway keeps collecting and stores data locally, then forwards it when the connection returns, so no readings are lost during an outage. This store-and-forward behaviour is quietly essential to a trustworthy historian and twin.

It is an edge processor: it can filter, aggregate, run local rules or light analytics, and even execute control loops on-site, deciding what to handle locally and what to send up. And it is a security boundary, the controlled point where the segmented building (OT) network meets the outside world. A well-designed gateway is why a building can be both locally autonomous and globally connected at once.

Gateways come in many sizes, from a small protocol converter doing one translation to a rugged industrial edge computer running containers of analytics and control. The right one depends on how much you intend to push to the edge. What they share is a position of trust: because a gateway can see and shape the whole data stream, it is also a prime target, so it must be hardened, patched and monitored like the critical infrastructure it is - again, work for qualified security professionals, not an afterthought bolted on at handover.

Because each layer has a distinct strength, real systems are hybrid - sometimes called fog computing, spreading work across a continuum from device to edge to cloud. Consider a smart office again.

At the edge, gateways run the fast, local and sensitive work: an occupancy-driven lighting loop reacts in milliseconds without any cloud call; camera feeds are processed on-site to a simple people-count so raw footage never leaves the building; and if the internet drops, comfort and lighting keep running while the gateway buffers every reading. Meanwhile the gateway forwards a filtered, summarised stream to the cloud, where a long-term historian keeps years of data, machine-learning models predict equipment failures across the whole portfolio, and the rich, comparative digital twin lives - reachable by the facilities team from anywhere.

The result is the best of both: instant, resilient, private control on-site; deep, durable, cross-building intelligence in the cloud; and a gateway stitching them together. For a twin this is decisive - a purely cloud twin is fragile and laggy, a purely edge twin cannot see the big picture, but a hybrid gives you a twin that is both responsive and wise. That balance, drawn deliberately, is the last piece of the connectivity puzzle before we turn, in Module 3, to the BMS that actually runs the plant.

A final caution keeps the hype in check. Vendors sell both extremes hard - some pushing an all-cloud platform, others an all-edge appliance - and both pitches over-simplify. The right split is a judgement about your building: its criticality, its connectivity, its privacy obligations and its budget. Ask of any product where each workload actually runs, what happens when the internet drops, and who can see the raw data. If those answers are vague, then the architecture is not yet real - and a twin built on a vague, hand-waved architecture will always disappoint in operation.