Building Automation Systems: Types, Software, Controls and Vendors

Building automation systems: types, software layers and the vendors behind them

Photo by iSawRed on Unsplash.

Building automation systems keep a commercial building's plant running to schedule and setpoint: HVAC, lighting, access, and the related controls that most occupants never see. The phrase covers field controllers on plant, the supervisory front end estates open each morning, and the software stack that ties them together. For the component-level definition of what a BAS is, the glossary owns that ground. This piece covers building automation system types, the software layers operators actually buy, the vendors behind large installations, and where analytics sits on top of what is already installed.

Every commercial building of any size runs one of these systems, whether the owner calls it a BAS, a BMS, or, in EU regulatory language, a BACS. What varies between buildings is which generation of software is running it, how many vendors have layered systems on top of each other over the years, and whether anyone still gets useful information back out of it. Building controls and automation is the day-to-day job; ranked analytics is how portfolios turn that telemetry into a queue rather than another dashboard.

Types of building automation systems

Operators searching for types of building automation systems usually mean the plant domains a BAS covers, not the software-layer model below. Most commercial estates run several of these in parallel, often under one supervisory front end and sometimes as separate vendor islands.

HVAC. Heating, cooling, ventilation and the plant that feeds them. Field controllers hold the loops for AHUs, chillers, boilers and VAV boxes. This is usually the largest energy and comfort load in the building, and the first place drift shows up as cost.

Lighting. Schedules, daylight harvesting, occupancy-based dimming and emergency lighting interfaces. Lighting often shares the same BACnet or DALI backbone as HVAC, but many sites still run a separate lighting panel that never talks to the rest of the BAS cleanly.

Access control. Door controllers, readers and identity systems. Security teams often own this stack separately from facilities, which is why access telemetry is late to join a building-wide analytics feed even when the protocol is already open.

Fire and life safety. Detection, notification and damper/fan override logic. These systems are heavily regulated and usually stay on their own panel. An analytics layer may read status where the integrator allows it; it does not replace the certified fire system.

Energy. Meters, sub-meters, and the points that turn kWh into cost and carbon. Energy is sometimes sold as its own building automation package, and sometimes as a thin set of points inside the HVAC BAS. Either way, without reliable metering the rest of the stack cannot price what it finds.

Analytics as the sixth layer. The five domains above produce telemetry. An analytics layer reads across them, checks readings against each other, and ranks what needs attention by cost or risk. It is not a sixth plant controller. It sits above HVAC, lighting, access, fire status and energy meters so a portfolio sees one queue instead of five islands. Building automation system types still start with the plant domains; analytics is how you use them together without ripping out a functioning BAS.

That list is what most UK operators mean by building automation system types. The next section is a different cut: the software layers that implement those domains.

The three layers of building automation software

Field-level software lives inside the controllers themselves: direct digital controllers running the control loops that turn a sensor reading into a command to a valve or a fan. Controllers, panels and field devices are the hardware anatomy inside a BMS controller. Above that sits the supervisory layer, sometimes a vendor's own front end, sometimes a Tridium Niagara station abstracting several vendors into one interface, where an operator sets schedules and watches trends. Above that again, increasingly, sits an analytics layer: software that reads the telemetry the first two layers already produce and turns it into a prioritised list of what needs attention.

That third layer is a relatively new category, and it is the one growing fastest. The field and supervisory layers have looked broadly similar for two decades; what has changed is the appetite for getting more out of the data they were already generating, without ripping out a functioning BAS to do it.

In practice, most existing buildings run several generations of these layers stacked on top of each other. A retrofit adds a new front end without touching the field controllers underneath it; a portfolio grown through acquisition inherits three different supervisory platforms across three buildings. None of that is a problem for an analytics layer, as long as it can read the protocol underneath. It is a problem for anyone trying to get one consistent view out of the front-end layer alone.

BAS software, building controls and analytics aren't the same thing

The terms get used interchangeably, but they describe different jobs. Building controls is the hardware and firmware that actually opens a valve or dims a light, sitting inside the field controllers. Building automation system software is the broader package: the controls plus the supervisory front end that schedules and monitors them. Fault detection and diagnostics (FDD) is a narrower add-on, usually rule-based, that compares expected against actual equipment behaviour and flags a mismatch. None of the three replaces the others; a building typically runs all of them at once, installed in different decades by different contractors.

Analytics is the newest of the four, and the one most often confused with FDD. Where FDD runs fixed rules against a handful of known fault signatures, a full analytics platform reads across every system a building has, HVAC, metering, IoT, checks the readings against each other before trusting them, and ranks what it finds by cost rather than by which rule fired. FDD asks whether a specific known pattern occurred; analytics asks what, out of everything happening in the building right now, is worth an operator's next hour.

The building automation vendor landscape

A short list of vendors accounts for most large-building installations: Honeywell, Johnson Controls (Metasys), Siemens (Desigo), and Schneider Electric (EcoStruxure Building), alongside Tridium's Niagara framework running underneath a lot of multi-vendor sites. A single portfolio often runs two or three of these side by side, the legacy of different buildings being commissioned in different decades by different contractors.

We treat all of them as integration targets, not competitors. Explore reads a building's existing BAS over its native protocol or vendor API rather than asking anyone to standardise on one platform first. Our integrations hub covers the specifics for Siemens Desigo, Schneider EcoStruxure, Honeywell's Niagara-based stations, Johnson Controls Metasys and Honeywell Trend, including what each exposes and how the connection gets set up.

Vendor lock-in in building automation rarely comes from the protocol itself; BACnet and Modbus are open standards no matter who sold the panel. It comes from licensing: per-point fees, seat-based access to the front end, and proprietary extensions that only that vendor's own tools read cleanly. A building can run an open protocol underneath and still be locked into one vendor's software to get full value out of the data it produces.

Choosing building automation software

Most estates do not choose building automation software from a blank sheet; they inherit whatever was specified at construction or the last major retrofit, then live with it. Where there is a real choice, mostly at new-build or full BAS replacement, the decisions that matter most are how open the protocol layer is (BACnet and open Niagara stations are far easier to build on than a closed proprietary bus), how much of the existing field wiring and controllers survive the switch, and whether the front end can be extended or has to be replaced wholesale to get new capability.

The harder question, for most buildings, is not which BAS to buy. It is what to do with the one already installed. Replacing a functioning BAS to get better visibility is expensive and disruptive, and the field controllers and wiring are usually fine; the value being lost sits upstream, in how the data gets used, not in the control layer itself.

Total cost of ownership is where a lot of these decisions go wrong. The purchase price of a new front end is usually a small fraction of what a building spends over the following decade on licensing, integration work and the technician hours needed to keep the point list current. A cheaper system with expensive integration debt often costs more by year five than the option that looked pricier on day one.

Where FrostLogic Explore fits

Explore sits on top of whichever BAS is already running. Write access starts off over BACnet, Modbus, OPC UA, oBIX or a vendor API depending on what is installed. Write access stays off until you grant it a scope. The FrostLogic Edge Agent can write setpoints and schedules inside those scopes without replacing the integrator's control logic; see Automation for how permissioned write-back is scoped. Outside a granted scope, Explore never takes over a damper or a chiller, and it is not a replacement for the BAS underneath it. It is an analytics layer that turns the data the BAS is already producing into a ranked queue of what is costing money or heading toward a failure, evidenced and priced rather than buried in an alarm panel. For how that works across a portfolio of buildings and BAS generations, see our BMS analytics platform page. The energy half of that queue is Explore's energy management layer; continuous meter reads sit under Explore's continuous meter layer.

Because Explore reads whichever protocol a portfolio already runs, one deployment can span buildings on entirely different building automation platforms without forcing them onto a single vendor's stack first. That matters most for portfolios assembled through acquisition, where standardising the BAS itself is rarely worth the disruption, but standardising what gets read out of it is straightforward.

That also means Explore is not a CMMS. It surfaces and ranks what is wrong; logging a work order and dispatching a technician stays with whatever maintenance system a team already runs.

FAQ

What is building automation system software? It is the software that runs a building's HVAC, lighting, access control and related systems automatically: field controllers running the control loops, a supervisory front end for schedules and trends, and increasingly an analytics layer that reads across both. See our glossary entry for the component-level breakdown.

What types of building automation systems exist? Most commercial sites cover HVAC, lighting, access control, fire and life safety, and energy metering as plant domains, often under one supervisory front end. Analytics sits above those domains as a sixth layer that ranks findings across them. The software-layer cut (field, supervisory, analytics) is a different model of the same stack.

What are the biggest building automation companies? Honeywell, Johnson Controls (Metasys), Siemens (Desigo) and Schneider Electric (EcoStruxure Building) run most large commercial installations, often alongside Tridium's Niagara framework tying multiple vendors together. Most portfolios of any size run more than one.

Is a building automation system the same as a BMS? Yes. BAS (building automation system) and BMS (building management system) describe the same category of system; BAS is more common in North America, BMS more common in Europe. Neither term implies a specific vendor or protocol.

Does FrostLogic replace my existing building automation system? No. Write access starts off over your BAS native protocol or vendor API, and adds an analytics layer on top. Write access stays off until you grant it a scope; the Edge Agent can then write setpoints and schedules inside that scope without replacing the BAS underneath it.

How does FrostLogic integrate with Siemens, Schneider, Honeywell or Metasys systems? Through each vendor's native protocol or API rather than a forklift upgrade. Our integrations hub covers the specifics for each.

Not sure which layer is costing you the most?

If you're weighing a BAS replacement against adding analytics on top of what's already installed, tell us what's running and we'll give you a straight answer, including when the honest answer is that a new BAS isn't the fix. 30 or 60 minutes, your pick. No commitment either way. Talk it through.