BAS
Building Automation System (BAS)
How a building automation system works: field devices, controllers and supervision, the protocols that connect them, and how to scope points, alarms and commissioning.
What a building automation system controls
A building automation system covers the mechanical and electrical services that keep a building usable: heating and cooling plant, air-handling units, fan coils, underfloor heating, ventilation, lighting, shading, pumps and metering. It does not replace the fire panel, the access controller or the utility meter; it supervises them, applies schedules and interlocks, and records what happened. The practical boundary is the point schedule: every sensor, command, status and alarm the building team needs to see or act on. A point can be an analogue input from a temperature sensor, a digital input from a pump status contact, an analogue output to a valve, a digital output to a fan, a pulse count from a meter or a calculated value such as a running average. If a point is outside that schedule, it is outside the BAS scope, however capable the controller. The BAS is the layer most owners mean when they ask who controls the building.
- Heating, cooling and ventilation sequences
- Lighting and shading by zone or room
- Metering, alarms and trend logs
- Status and interlocks from third-party systems
- Analogue, digital, pulse and calculated points
Three layers, one operating model
Most BAS architectures are described in three layers. Field devices — sensors, actuators, valves, dampers and meters — sit closest to the plant. Controllers execute the control logic: PID loops, schedules, staging and safety interlocks. The supervisory layer normalises data from many controllers and protocols into one model, then presents alarms, trends and commands to operators. The layers matter commercially because they assign responsibility. A controls contractor may own the field and controller layers, while an integrator owns supervision and reporting. Clear boundaries stop two teams from claiming the same point, and make the handover document worth reading. A flat architecture with fewer gateways is also easier to diagnose than a deep chain of translations. In practice, the controller layer must keep running when the supervisory network is unavailable; a building that stops heating because a switch or server has failed is an architecture fault, not an operator error.
- Field: sensors, actuators and meters
- Control: local sequences that survive network loss
- Supervision: one data model and alarm list
- Application: dashboards, reports and mobile access
Protocols and openness
A BAS is only as open as its interfaces. BACnet/IP is common for chillers, AHUs and packaged plant; Modbus RTU or TCP for meters, inverters and sensors; KNX for lighting, shading and room control; DALI for addressable luminaires; and dry contacts for legacy equipment that offers nothing else. Open protocols do not remove integration work. Each interface still needs an address list, a point map, a naming convention and a test record. BACnet alone offers objects, properties and services, and a device may support only a subset; Modbus offers registers with vendor-specific scaling; KNX uses group addresses that must be named and documented. The useful question is not which protocol is preferable in principle, but which interface the installed equipment actually exposes, and who is responsible for mapping it. Good integration documentation names the gateway, the firmware version and the fallback behaviour.
- BACnet/IP for plant and air-handling units
- Modbus RTU or TCP for meters and inverters
- KNX and DALI for lighting and shading
- Dry contacts and APIs for legacy systems
Points, schedules and alarms
The point schedule is the contract of a BAS project. It lists every input, output, setpoint, status and alarm with its address, range, engineering units and alarm limits. Schedules decide when plant runs; interlocks decide what must happen when two systems meet; alarm rationalisation decides which events reach an operator and in what order. A large point count with no naming convention is harder to operate than a smaller system with a disciplined schedule. Commissioning tests the schedule point by point, not the graphics. The test record is what proves the building works as specified, and trends provide the evidence for tuning long after the commissioning team has left. Trends also need a stated interval: a one-minute sample is useful for plant sequencing, while a fifteen-minute sample is usually enough for energy reporting. The point schedule should say which is which.
- Naming that matches the drawings
- Alarm limits and deadbands written down
- Interlocks tested, not assumed
- Trends kept for performance review
BAS, BMS and IBMS are not the same thing
BAS and BMS are often used interchangeably: both describe the control and management of building services. IBMS goes further. It integrates the BMS with access control, CCTV, parking, energy meters, guest rooms and fire status, then applies cross-system rules and presents one operating picture. The distinction is architectural, not a ranking. A building can have a competent BAS and no IBMS, or an IBMS that supervises several BAS installations. The scope should say which layer is being bought, which systems sit inside it, and which systems remain independent. That clarity protects both the budget and the operating model. It also prevents a common procurement error: buying an integration platform before the underlying plant control is stable, then blaming the platform for mechanical and commissioning faults.
- BAS: plant and room control
- BMS: supervision of building services
- IBMS: multi-subsystem integration
- Fire and access retain their own authority
Scoping a BAS project
A useful BAS scope starts with the building, not the product. List the systems, their vendors and versions, the protocols they expose and the points the operator needs. Then agree the sequences: what runs on a schedule, what follows occupancy, what must fail safe, and what the building team can change without a programmer. Retrofit projects need an audit of existing controllers and wiring before a new head-end is proposed. New-build projects need the point schedule agreed before the controls package is tendered. In both cases, commissioning and training belong in the scope, not in a later conversation after handover. A written scope is cheaper than a change order. It should also state the acceptance tests, the documentation deliverables and the support period, because those are the parts most often omitted when a price is compared.
- System and protocol inventory
- Sequences and alarm philosophy
- Point schedule and naming
- Commissioning, training and documentation
Control sequences that make the system work
Sequences are where a BAS becomes useful. A typical AHU sequence has occupied and unoccupied modes, an optimum-start calculation, supply-air temperature control, economiser or free-cooling logic, demand-controlled ventilation, filter monitoring and frost protection. A chiller sequence stages machines by load, rotates lead and lag, protects minimum run times and maximum starts, and resets chilled-water temperature within limits. Pump sequences maintain differential pressure, rotate duty and standby, and prove flow before a machine is enabled. Room sequences handle changeover between heating and cooling, window contacts, occupancy and setpoint limits. Each sequence needs modes, transitions, setpoints, time delays and a defined failure position. The written sequence of operation is the reference for configuration, testing and later changes; a sequence that exists only in the programmer's head cannot be commissioned or maintained.
- AHU modes and transitions
- Chiller staging and rotation
- Pump lead/lag and flow proof
- Setpoint limits and fail-safe positions
Commissioning, documentation and common failure modes
Commissioning proves the point schedule, not the screensaver. It starts with panel checks and point-to-point verification, continues with sensor calibration checks, valve and damper stroke tests, alarm tests and interlock tests, and ends with failure-mode tests: what happens when a sensor fails, a bus segment is lost or a controller restarts. Seasonal testing confirms heating and cooling under real load. As an industry planning reference, small projects are often allowed a few weeks for commissioning and large projects several months, but the actual duration follows point count, trade readiness and site access. Documentation should include as-built drawings, the point schedule, sequences, test records, network diagrams and configuration backups. Common failures are predictable: sensors placed in dead air, valves oversized or leaking, control loops left hunting, overrides left in place, duplicate point names, and gateways installed without a point map.
- Point-to-point and stroke tests
- Failure-mode and seasonal tests
- As-built drawings and backups
- Overrides and naming checked at handover
Typical BAS scope by subsystem
18 rows| Subsystem | What the BAS controls | Common interface | Operator value |
|---|---|---|---|
| HVAC plant | Chiller and boiler staging, pumps, valves, setpoints | BACnet/IP, Modbus, 0–10 V | Plant runs to demand, not a fixed clock |
| Chillers and heat pumps | Stage capacity, reset chilled-water setpoint, balance run hours | BACnet/IP, Modbus, dry contacts | Stable capacity with fewer starts |
| Boilers and heat sources | Stage heat sources, protect return temperature, apply weather compensation | BACnet, Modbus, 0–10 V, dry contacts | Safe heat supply at part load |
| Air-handling units | Supply-air temperature, dampers, fans, filters, frost protection | BACnet/IP, Modbus, dry contacts | Consistent fresh air and comfort |
| Fan coil units | Room setpoints, valve and fan speed, occupancy mode | Modbus, KNX, 0–10 V | Room-level comfort with less waste |
| Underfloor heating | Slab temperature, mixing valve, weather compensation | Modbus, 0–10 V, dry contacts | Stable heat without overshoot |
| Domestic hot water | Storage temperature, circulation, scheduled pasteurisation | Modbus, 0–10 V, dry contacts | Safe hot water without standing losses |
| Ventilation and exhaust | Demand-controlled fresh air, pressure, fan status | Modbus, 0–10 V, dry contacts | Fresh air matched to occupancy |
| Lighting | Switching, dimming, scenes, occupancy and daylight | DALI, KNX, relays | Light follows use |
| Shading | Solar tracking, wind protection, privacy scenes | KNX, Modbus, dry contacts | Glare and heat controlled |
| Metering | Electricity, water, gas, heat and sub-metering | Modbus, M-Bus via gateway, pulses | Consumption visible by area |
| Access integration | Door status, release, event linkage | API, OSDP via controller, dry contacts | One event, not several interfaces |
| CCTV and intrusion | Camera health, alarm events, recording status | ONVIF, API, dry contacts | One event view without a second workstation |
| Fire status | Alarm and pre-alarm status only | Dry contacts, supervised inputs | Fire panel keeps authority |
| Lifts | Status, fault and alarm signals | Dry contacts, API | Service issues visible early |
| Pumps and valves | Start/stop, speed, position, fault | BACnet, Modbus, 0–10 V | Plant sequencing and fault detection |
| Room and guest-room control | Setpoints, occupancy, window contacts, scenes | KNX, Modbus, 0–10 V | Comfort with energy limits |
| Alarms and trends | Normalised events, history and reports | Supervisory layer | Faster diagnosis and review |
Project images
3 images
Frequently asked
01What is a building automation system?
A building automation system controls and supervises building services such as HVAC, lighting, shading and metering. It connects field devices, runs schedules and interlocks, and gives operators alarms, trends and a common view of the plant.
02What is the difference between BAS and BMS?
The terms overlap. BAS usually emphasises the automatic control of plant and room services; BMS emphasises supervision and management of those services. Some projects use them as synonyms. The scope document matters more than the label.
03Do we have to replace our existing controllers?
Not necessarily. If existing controllers expose BACnet, Modbus, KNX or another usable interface, they can often be integrated. The audit confirms what data is available and what remains read-only.
04Which protocols should a building automation system support?
Support what the installed equipment provides. BACnet/IP, Modbus RTU and TCP, KNX, DALI and dry contacts cover most building services. The correct set is defined by the equipment list, not by a preference for one protocol.
05How many points does a building need?
There is no reliable rule without a system list. Point count depends on the equipment, the control strategy and how much status the operator needs. We build the point schedule during the audit and use it to size controllers and price the work.
06Can a building automation system run without the internet?
Yes. Control logic, schedules and interlocks should run locally in the controllers. Internet connectivity is for remote access and reporting, not for keeping the building running.
07How long does commissioning take?
It depends on the number of points, the readiness of other trades and the testing sequence. We define milestones after the audit and test in stages: panel checks, point-to-point tests, interlock tests and seasonal verification.
08What does a building automation system cost?
Price follows scope: the point schedule, the systems integrated, the gateways, the graphics and the commissioning effort. We do not publish list prices. The pricing page explains the method and the three scope tiers.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.