What a BMS actually is
The short version, before the deep end.
A Building Management System (BMS) - also called a Building Automation System (BAS), and IBMS when fire, security and lifts are folded into the same head-end - is the layer of sensors, controllers, software and wiring that watches and runs a building's mechanical and electrical plant automatically: HVAC, lighting, power monitoring, and the interfaces into life-safety and vertical-transport systems. It is not one product. It's an ecosystem of field devices, field-level networks, controllers, and supervisory software, all agreeing on how to talk to each other.
What it does, in practice
- Monitors - reads temperatures, pressures, flows, statuses and faults across the building continuously.
- Controls - positions dampers and valves, starts/stops fans and pumps, stages chillers and boilers to hold setpoint.
- Schedules - runs equipment on time-of-day/occupancy programs instead of leaving it running 24/7.
- Alarms - flags out-of-range conditions and equipment failures to an operator, by severity.
- Trends & reports - logs point history for energy reporting, fault diagnosis and compliance (LEED, ESG, utility billing).
- Optimizes - sequences plant (chiller staging, economizer free-cooling, demand-controlled ventilation) to cut energy use without a human in the loop.
Related acronyms, disambiguated
| BAS | Building Automation System - same thing as BMS; US-favoured term. |
| IBMS | Integrated BMS - HVAC + fire + security + lifts + lighting on one head-end/graphics layer (systems usually stay independently certified underneath). |
| EMS | Energy Management System - a BMS subset or overlay focused on metering and consumption reporting. |
| DDC | Direct Digital Control - the controller doing the actual closed-loop control (the "brain" behind a BMS point). |
| SCADA | Supervisory Control & Data Acquisition - the industrial-plant cousin of a BMS; same concepts, heavier-duty context. |
System architecture - the three tiers
Every BMS, regardless of brand, is built from the same three layers stacked on top of each other.
Sensors, actuators, relays and the small terminal-unit controllers wired directly to them (one VAV, one FCU, one AHU per controller). Talks hardwired I/O out to the device, and MS/TP or a similar serial bus back to its supervisor.
Network/building/supervisory controllers (e.g. a JCI NAE, Distech ECY, Siemens PXC, a Niagara JACE) that poll a trunk of field controllers, run the plant-wide sequences of operation, and bridge onto the IP backbone.
The head-end server, database, graphics and web/mobile client operators actually look at - alarms, trends, schedules, reports. Increasingly mirrored to a cloud tenant for portfolio-wide analytics.
Protocols - how devices actually talk
A BMS is really a translation problem. Field devices speak one of a handful of standard languages, plus whatever proprietary dialect the equipment vendor shipped - everything above the field trunk is gateways and object mapping.
| Protocol | Openness | Physical / transport | Where it's used | Practical node limit |
|---|---|---|---|---|
| BACnet MS/TP | Open (ANSI/ASHRAE 135) | RS-485 serial, twisted pair | Field trunk - controller to controller | 32 / segment (no repeater) |
| BACnet/IP | Open (ANSI/ASHRAE 135) | Ethernet / UDP | Backbone - controller to server | Network-limited |
| BACnet/SC | Open (135-2020 addendum) | TLS over WebSocket/IP | Encrypted backbone, cloud, campus WAN | Network-limited |
| Modbus RTU | Open (de facto) | RS-485 serial | Chillers, meters, VFDs, gensets | 32 / segment (no repeater) |
| Modbus TCP | Open (de facto) | Ethernet | PLC & meter integration | Network-limited |
| LonWorks / LonTalk | Open (ISO/IEC 14908) | Free-topology twisted pair (FTT-10) | Legacy field devices, some lighting | ~64 / segment |
| KNX | Open (ISO/IEC 14543) | Twisted pair (TP1), IP, RF | Lighting, blinds, room control | 64 / line |
| M-Bus | Open (EN 13757) | Twisted pair, low voltage | Utility & energy sub-metering | ~250 / segment |
| OPC UA | Open (IEC 62541) | Ethernet | BMS ↔ IT/SCADA bridging | Network-limited |
| MQTT | Open (OASIS) | TCP/IP | IoT sensor telemetry, cloud dashboards | Network-limited |
| Proprietary (N2, CCN, Comm5, P1/FLN…) | Closed | Vendor serial bus | Legacy single-vendor estates | Vendor-defined |
Wiring & topology
Almost every "flaky point" service call traces back to one of the rules on this sheet.
Bus topology - how an RS-485 trunk is actually run
Grounding & shielding
- Ground the cable shield / drain wire at one end only - normally at the automation controller end. Grounding both ends turns the shield into a ground loop and injects noise instead of rejecting it.
- Keep the shield continuous through every device - pigtail it past each controller's terminal, don't cut and re-land it.
- Never use the shield as a signal or power conductor.
- 120 Ω termination resistors go at the two physical ends of the trunk only - not at every device, not in the middle.
- Some controllers need a separate bias resistor pair enabled if it isn't built in - check the IOM; without bias, an idle bus can float and miscount as a spurious byte.
Segregation from power
- Class 2 / ELV control and comms cabling must be run separate from line-voltage power per local electrical code (e.g. NEC 725, IEC 60364) - separate containment, or a physical barrier in a shared tray.
- Typical practice: minimum ~300 mm (12") parallel separation from power cable in open tray; cross power cabling at 90° where unavoidable.
- Keep analog signal cable (0–10V, 4–20mA, RTD) away from VFD output cabling specifically - VFD switching noise is the single worst offender for erratic analog readings.
- Route comms trunk and 24VAC power together only when using a purpose-built combi-cable rated for both, not by taping two cables side by side.
Typical (not universal) core-colour convention
Colour codes vary by contractor and project spec - always follow the project's cabling schedule, but this is what you'll see most often in the field.
| Conductor | Typical colour | Carries |
|---|---|---|
| Power + | Red | 24 VAC / 24 VDC controller & actuator power |
| Power − / common | Black | 24 VAC / 24 VDC common |
| Data A / + | Blue | RS-485 non-inverting |
| Data B / − | White / blue-white | RS-485 inverting |
| Shield drain | Green / bare | EMI shield, grounded one end |
Cable sizing reference
What to pull for each signal type. Confirm against the manufacturer's IOM and the project cable schedule - these are field-standard defaults, not a substitute for the spec.
| Signal / application | Cable type | Conductor size | Shielding | Max run | Notes |
|---|---|---|---|---|---|
| 24 VAC controller / actuator power | Multi-strand, jacketed | 18 AWG (0.75 mm²) | Unshielded | ~30 m | Step up to 16 AWG beyond ~30 m to hold voltage drop under 5%. |
| 24 VAC power, long runs | Multi-strand, jacketed | 16 AWG (1.5 mm²) | Unshielded | ~60 m | Beyond this, feed a local transformer instead of stretching one circuit. |
| BACnet MS/TP · Modbus RTU (RS-485) | STP, 100–120 Ω, e.g. Belden 3105A / 82760 / 9842 | 22 AWG (0.34 mm²) | Foil + drain, ground one end | 1200 m @ 9.6 kbps; ~300 m @ 76.8 kbps | 32 unit loads / segment without a repeater; use repeaters, not thicker cable, to extend the trunk. |
| LonWorks (FTT-10A) | UTP, e.g. Belden 8471 | 22 AWG | Unshielded (typ.) | 500 m bus / 450 m free-topology | Terminate per Echelon transformer-based termination, not a plain resistor. |
| KNX (TP1) | Dedicated KNX bus cable, 2×2×0.8 mm | ~22 AWG eq. | Unshielded, dedicated pair | 1000 m / line | Red/black is bus power+data; the second pair is spare, not general purpose. |
| Analog input, 0–10 VDC / 4–20 mA | STP | 18–22 AWG | Foil + drain, ground one end | <100 m recommended | Keep clear of VFD output cabling - the single biggest cause of noisy analog readings. |
| Thermistor / RTD temperature sensor | Twisted pair | 18–22 AWG | Shielded near EMI, else optional | <30 m unshielded | Conductor resistance adds directly to the reading on long runs - oversize rather than trust a correction factor. |
| Dry-contact digital input (status) | Twisted pair | 18–22 AWG | Optional | <150 m | Fine unshielded away from high-EMI sources (drives, contactors, ballasts). |
| Digital output (relay / 24 V actuator command) | Stranded | 18 AWG | Unshielded | Per load rating | Confirm the controller's triac/relay current rating before driving a coil directly. |
| BACnet/IP · Modbus TCP backbone | Cat6 / Cat6A UTP, or fibre | 23–24 AWG (copper) | Per cable rating (U/UTP, F/UTP) | 90 m copper; km-scale on single-mode fibre | Use fibre for inter-building or riser backbone runs beyond copper's reach. |
I/O point schedule generation
The single document everything else in a controls project gets sized against.
The I/O (input/output) point schedule lists every physical and network point the BMS will monitor or control, equipment by equipment. It drives controller selection (how many AI/AO/DI/DO does each controller need), panel and I/O module sizing, cable take-off, the commissioning checklist, and the cost estimate. Get it wrong and you either under-order I/O modules mid-project or pay for spare capacity nobody asked for.
How it's built
- Start from the mechanical & electrical equipment schedules - every AHU, FCU, VAV, pump, chiller, panel gets a row.
- Read the sequence of operations (SOO) for each system and list every variable it references - anything the sequence checks or commands becomes a point.
- Classify each point: AI analog input, AO analog output, DI digital/binary input, DO digital/binary output, NET a network object read through a gateway, or SW a software/virtual point that never touches a wire.
- Record units, range, and alarm limits for each analog point; record normal/active state for each digital point.
- Assign each point to a controller and tally I/O counts per controller against its physical terminal capacity.
- Add 10–20% spare I/O capacity per controller - a good-practice margin for scope creep and future retrofits, not a firm code requirement.
Try it - generate a typical point list
Pick the equipment on a project and get the typical I/O it needs. This is a teaching starting point - for a real quantity-based schedule with a project header, use the I/O point generator tab above.
Grand total
Fill in the job header, set a quantity against each equipment type, and the schedule builds itself below - with a running point total at the end of the sheet.
Equipment & quantity
| Equipment | Quantity | Points / unit | Subtotal |
|---|
Generated I/O point schedule
Grand total - I/O point schedule
What connects to a BMS - and what it watches
Expand any system for its typical point list. AI analog in · AO analog out · DI digital in · DO digital out · NET via gateway/network object.
Controllers & field devices
The hardware between a wire and a point on a graphic.
Controller tiers
Larger point count, runs plant-wide sequences (chiller staging, economizer logic), bridges the field trunk onto BACnet/IP. Examples of the role: JCI NAE, Siemens PXC, Distech ECY/ECB-VAV supervisors, a Tridium Niagara JACE. Typically holds the trend database buffer and schedules for its own trunk.
Small, dedicated I/O count, purpose-built for one piece of terminal equipment - one VAV box, one FCU, one heat pump. Examples of the role: JCI FEC/FAC, Siemens TEC/PXC-U, Distech ECB. Runs its own local control loop even if the network trunk goes down.
Sensors in the field
| Sensor | Common type | Measures |
|---|---|---|
| Temperature | 10 kΩ thermistor (Type II/III), Pt1000 RTD, or digital (BACnet MS/TP room sensor) | Room, duct, water, outside air |
| Humidity | Capacitive %RH element | Room / duct relative humidity |
| CO₂ | NDIR (non-dispersive infrared) | Space CO₂ ppm, drives demand-controlled ventilation |
| Pressure | Differential pressure transducer | Duct static pressure, filter differential, room pressurization |
| Flow | Airflow station / ultrasonic or magnetic water flow meter | Air volume, chilled/hot water flow |
| Occupancy | PIR or ultrasonic | Space occupied/unoccupied for setback control |
Actuators in the field
| Actuator | Signal | Fail-safe behaviour |
|---|---|---|
| Damper actuator - modulating | 0–10V / 2–10V / 4–20mA | Spring-return to a defined fail position (usually closed) on power loss |
| Damper actuator - on/off | 24V floating or two-position | Spring-return, or holds last position on non-spring types |
| Valve actuator - 2-way | 0–10V modulating or on/off | Throttles flow through one path; equal-percentage trim for modulating control |
| Valve actuator - 3-way | 0–10V modulating or on/off | Diverts/mixes between two paths at constant total flow |
Pneumatic actuation still exists in older estates but is largely retired in new work in favour of electronic actuators; an interposing relay is added wherever a controller's onboard triac/relay can't carry the load current a coil or contactor demands directly.
Brand comparison
Seven brands worth knowing, picked for spread rather than a strict ranking - three of the long-standing majors, three adjacent players with a genuinely different angle, and one independent open-integration specialist.
| Brand | Flagship platform | Native protocols | Strength | Best fit | Watch-out |
|---|
What the operator dashboard looks like
A live-ish mock-up, not a screenshot of any one product - every vendor's head-end arranges these same five things differently. Numbers move on a timer for feel; nothing here is a real building.
Chilled water supply temp °C, last 60 min
Active alarms 3
Plant equipment status
Today's schedule
Troubleshooting
Click a symptom for the diagnostic sequence a controls tech would actually run.
Fast-reference table
| Symptom | Likely cause | Fix |
|---|---|---|
| Controller offline on MS/TP | Wiring polarity swapped, missing termination, duplicate MAC address | Verify A/B polarity and end-of-line resistors; renumber the duplicate device |
| Point reads "Null" / stale on graphics | Gateway or network controller lost comms upstream, or the physical sensor failed | Check the immediate upstream hop first (gateway → trunk → device), then the sensor |
| Analog value noisy / jumping | Unshielded or co-routed with VFD/power cabling, missing or double-grounded shield | Re-route away from power, confirm single-end shield ground |
| Actuator hunting (won't settle) | PID loop tuned too aggressively, or a mechanically undersized/oversized valve | Re-tune gain/integral time; check valve authority against the loop it's serving |
| Schedule not executing | Controller time not synced, holiday/exception calendar overriding it, or a manual override left active | Confirm time sync source, check calendar exceptions, clear overrides |
| Trend graph flat-lined | Sample/COV interval too coarse, or trend buffer not being polled by the head-end | Check trend configuration and last-archived timestamp |
Commissioning checklist
The handover sequence, roughly in order.
Before functional testing
- Point-to-point verification - every physical point forced/read at the field device and confirmed on the graphic, both directions.
- Sensor calibration check against a reference instrument.
- Actuator stroke test - full travel, confirm fail-safe position on power loss.
- Network health check - trunk error rate, duplicate addresses, termination present at both ends.
Functional & handover
- Functional performance testing (FPT) - exercise every mode in the sequence of operations, not just the default state.
- Seasonal/mode retest where the sequence changes behaviour (e.g. economizer, heating/cooling changeover).
- Trend log review across a full operating cycle before sign-off.
- As-built graphics, point schedule and network riser diagram handed over, matching what's actually installed.
- O&M manual and operator training delivered; defects-liability-period monitoring plan agreed.
Glossary
Material submission review
What to check when a contractor's technical submittal lands on your desk, before it gets an "approved" stamp. Tick items off as you go - your progress stays on this device only.
Shop drawing review
Everything to check on a BMS shop drawing package, from containment on the reflected ceiling plan down to the last cable termination.
Live equipment simulator
Push a command and watch the field respond, the way it actually behaves: a command point goes out, the equipment takes a moment to prove it, and only then does the physical device start moving.
Virtual field devices
The basic building blocks - toggle each one on its own.
Equipment simulators
Push the command, watch the DI status confirm, then watch the plant actually start. The thermometer chases the real setpoint only once the equipment is genuinely proven running - exactly how it works in the field.
Chiller plant start sequence - where the I/O schedule comes from
This is the exact logic a sequence of operations describes in words and an I/O schedule turns into points: every command on this diagram is a DO, every confirmation is a DI, and each DI is the permissive that unlocks the next DO.
Engineer’s notes
Field notes - the things that are obvious in hindsight and expensive to learn on-site.