What are the main components of a smart building?

Underneath the branding, a smart building has five functional layers. Field devices sense and act, under the control of the building's automation systems. Networks carry the information. Integration connects one system to another and, through a data model, gives the information a meaning software can use. Applications turn it into decisions. The fifth layer is the one brochures leave out: the people, contracts and processes that keep everything working after handover.

Think of them as functions to be delivered. A single product may cover several layers, and one layer may involve several suppliers. A good brief describes what each function has to achieve and leaves the design to decide how many products that takes.

Field devices and controllers

Sensors and actuators

Sensors observe conditions such as temperature, humidity, carbon dioxide, occupancy, energy, water flow and equipment status. Actuators change something: valves, dampers, drives, relays and lighting drivers.

Every application above depends on this layer, so the specification has to be precise about measurement range and accuracy for the intended use, calibration and replacement intervals, mounting locations and power source. For wireless devices it also has to settle battery life and who replaces the batteries. An analytics application is only as good as the sensor feeding it, and a badly placed room sensor produces data that is confident but misleading.

Controllers and automation

Controllers apply control sequences: they read inputs, apply logic and drive outputs. In most commercial buildings this means the building management system (BMS), sometimes called a building automation system (BAS), alongside dedicated controllers for lighting, lifts, access, fire and specialist plant.

The critical decisions here are which functions must run locally in a controller and keep working if the network or a server fails, which sequences are required, and who owns the control logic after handover. Life-safety systems keep their own certified controls, and their interfaces with other systems should be limited and deliberately designed.

Networks and connectivity

The network carries information between devices, controllers, servers and external services. It may combine structured cabling, Power over Ethernet, serial field buses, Wi-Fi and low-power wireless such as LoRaWAN.

Not all traffic is equal. A meter sending a reading every 15 minutes and a command to a smoke damper have very different requirements, which is why the design should start from an endpoint schedule and segment systems according to risk and ownership. Critical switches need resilience and backup power, and somebody has to be named as the network's administrator.

Integration and the data model

Integration

Integration moves data and, where authorised, commands between systems, using protocols such as BACnet, Modbus, KNX, MQTT or vendor APIs, with gateways translating between them.

"Open protocol" on a datasheet is not an interface specification. What the owner needs is an interface schedule listing each connection, the data and commands it carries, the protocol and version, the expected performance, the behaviour on failure and the supplier responsible at each end.

The data model

This is the part that is often missing. A value such as "21.4" becomes useful only when the system knows it is a zone air temperature in degrees Celsius, measured in room 3.12, served by a particular fan-coil unit, at a particular time. A semantic model records those relationships in a form software can query.

Brick, an open schema that represents equipment, points and spaces as a graph of linked entities, is one way of doing this. Project Haystack takes a tag-based approach, and ASHRAE's proposed Standard 223P addresses the same problem. Choosing a schema is the easy part. The effort lies in mapping every installed point accurately and keeping the model current as equipment changes, so the contract should state the naming convention, the schema and version if one is required, who builds the model, how it is validated and who updates it after alterations.

Applications

Applications are where the data gets used: energy dashboards, fault detection and diagnostics, maintenance management, room booking, tenant apps and portfolio reporting.

Each one should justify itself in plain terms: who uses it, which decision it supports, what action follows and how success is checked. A visualisation nobody reviews is not an improvement; it is a recurring licence and maintenance cost.

Operations, support and governance

Devices drift, batteries run down, software needs updating and contracts end. Each of those realities needs an owner. The support arrangements should set response and restoration targets, assign responsibility for updates, backup and recovery, control which users and suppliers have access, train named roles and guarantee that data access continues if a supplier is replaced.

How the layers depend on each other

The layers form a chain, and a weakness anywhere limits everything above it. A single alert shows how many links are involved.

Where things usually go wrong

Each element has a characteristic weakness, and each has a safeguard the owner can write into the contract.

Specifying the whole service

The discipline that ties this together is simple to state. For each use case, trace the chain from sensor to action and name the owner of every link. Test the whole chain before acceptance, including what happens when a link fails. Only then decide which products cover which layers.