If you’ve worked with building-automation systems for more than ten minutes, you’ve encountered an alphabet soup of acronyms that vendors use differently, RFPs use loosely, and inspectors use sometimes contradictorily. This is a working reference — what the terms mean, where they overlap, when to use which, and the gotchas that keep showing up on projects.
We’ve grouped them into four sections: systems, protocols, hardware, and the contemporary IP transition that’s changing how most of the above gets implemented.
Systems
The system-level acronyms describe the thing being built, not how it’s built. The overlap between them is real and unhelpful.
- BAS — Building Automation System. The general term for any system that monitors and controls building equipment: HVAC, lighting, access control, sometimes life safety. The most-used term in North America.
- BMS — Building Management System. Functionally a superset of BAS, though many vendors use the two interchangeably. When a distinction is drawn, BMS usually implies a centralized management head end with reporting and analytics, while BAS implies the controllers and field devices. In practice the distinction is blurry.
- BCS — Building Control System. Less common; treat as a synonym for BAS.
- EMS — Energy Management System. A BAS variant focused specifically on energy: sub-metering, demand-response, load shedding, utility-rate optimization. Often a layer on top of BAS, not a replacement for it.
- IBMS — Integrated Building Management System. A BMS that has been integrated with other facility systems (fire alarm, security, IT infrastructure). The “I” matters — it implies the systems share data, not just share a building.
When a spec sheet uses one of these terms, the safe assumption is that the author meant the broadest possible meaning of the word. If the distinction matters for your project — say, you need EMS-grade sub-metering and the spec just says BAS — that’s a clarifying question to ask before quoting.
Protocols
Protocols are how the controllers talk to each other and to the field devices. The protocol landscape in BAS is one of the messier parts of the industry because most buildings have multiple protocols running side by side, and the gateways between them are where compatibility issues live.
BACnet
The dominant open protocol for HVAC and building controls. Defined by ASHRAE Standard 135. Speaks over several physical media:
- BACnet MS/TP — Master-Slave/Token-Passing, runs over RS-485. The legacy serial flavor. Slow (typically 9,600–76,800 baud) but cheap to install and very durable. Still extremely common in retrofits and small commercial installs.
- BACnet/IP — BACnet over UDP/IP. The modern flavor. Fast, routable, fits into the building’s IT infrastructure. The default for new construction at this point.
- BACnet/SC — Secure Connect. BACnet over WebSockets with TLS. The cybersecurity-conscious flavor, gaining adoption since IT departments started caring about BAS.
When someone says “BACnet” without qualifying it, ask whether they mean MS/TP or IP. The difference matters a lot for the panel design and the building network architecture.
Modbus
Older and simpler than BACnet. Originally a serial protocol; the modern Modbus TCP variant runs over Ethernet. Two flavors you’ll encounter:
- Modbus RTU — the serial flavor, over RS-485 or RS-232. Ubiquitous on legacy gear and on many third-party devices (variable-frequency drives, energy meters, pumps).
- Modbus TCP — the Ethernet flavor. Same data model, IP transport.
Modbus has no native discovery or naming model — you address devices by unit ID and read/write registers by address. This makes Modbus faster to implement but worse to maintain than BACnet, where devices self-describe with names and units.
LonWorks
A protocol family from the late 1990s, still found on installations from that era. Less common in new builds. If you’re touching a LonWorks installation, expect to find specialized hardware and a shrinking pool of techs who know it well.
KNX
European-dominant building control protocol. You’ll see it more on European-headquartered properties and on lighting-heavy installs. Less common in North American HVAC.
MQTT
Not a building-automation protocol in the traditional sense, but showing up in newer integrations as the message-bus layer between BAS and cloud-analytics platforms. If a vendor proposal mentions “IoT-style integration,” MQTT is usually what’s under the hood.
Hardware vocabulary
The hardware terms describe the physical devices in the panel and in the field. The terminology is less standardized than the protocols, but a few terms come up often:
- DDC — Direct Digital Control. The controller chip or module that runs the local equipment logic. Lives on or near the equipment being controlled.
- IO module / I/O expansion — A device that adds input and output points to a DDC. Often grouped by signal type: digital in, digital out, analog in (0–10V or 4–20mA), analog out, RTD inputs for temperature sensors.
- RTU — Remote Terminal Unit. A controller out in the field, not in the main panel. Confusingly, “RTU” in HVAC also means “Rooftop Unit” — the air-handling equipment. Same acronym, two completely different meanings, context matters.
- PLC — Programmable Logic Controller. The industrial-controls cousin of the DDC. Common in plant and process applications; less common in pure BAS but increasingly seen on integrated industrial-and-building deployments.
- VFD — Variable-Frequency Drive. Drives motors at variable speeds. Talks to the BAS via Modbus or BACnet to receive setpoints.
- Gateway — A device that translates between two protocols (e.g., BACnet to Modbus, or BACnet/IP to BACnet MS/TP). Every building has them; they’re the duct tape of building automation.
- Network controller / supervisory controller — A larger controller that aggregates data from multiple DDCs and presents a higher-level interface. In the Niagara world this is a JACE; Tridium and others have similar branded variants.
The IP transition
The single biggest change in building automation over the past decade is the move from RS-485 serial protocols (BACnet MS/TP, Modbus RTU) to IP-based protocols (BACnet/IP, BACnet/SC, Modbus TCP). The transition is well underway but not complete.
What’s driving it
Three things:
- Speed. IP networks run orders of magnitude faster than RS-485. A modern Class A building has so many points to poll that serial buses can’t keep up.
- Standardization. Building IT teams already manage IP networks. Putting BAS on the same infrastructure means one cable plant, one management toolset, one set of monitoring tools.
- Cybersecurity. Once BAS connects to the internet — for remote access, cloud analytics, or vendor support — it becomes a security concern. IP-based protocols can carry TLS; serial protocols can’t.
What it changes for panel design
Panels destined for IP-based BAS look different from panels for serial BAS:
- RJ45 Ethernet jacks instead of (or alongside) RS-485 terminal blocks
- Managed switches built into the panel for VLAN isolation
- Network isolation between the BAS VLAN and the corporate LAN, usually via firewall rules managed by IT
- Cable plant that follows TIA 568 standards (Cat 6 or better, structured cabling)
- Documentation that’s legible to both BAS techs and IT staff
Our IT-aware panel designs walk through the architecture decisions in more detail.
The retrofit case
Most existing buildings have a mix. The BAS we install today usually sits alongside legacy MS/TP devices that aren’t worth replacing yet. The bridge is a gateway — usually built into the supervisory controller — that lets the IP backbone read MS/TP devices and the MS/TP devices keep running their local loops.
The retrofit math: replacing every MS/TP device on a 20-year-old installation usually doesn’t make economic sense. Replacing the backbone and the head-end while keeping the field devices on MS/TP almost always does.
When to ask the vendor
A few questions that surface real issues on most BAS proposals:
- “Which BACnet flavor? MS/TP, IP, or SC?”
- “What protocols does the gateway support and at what point counts?”
- “Where do the BAS VLAN and the corporate LAN actually separate?”
- “What’s the failure mode when the network controller goes offline — do the field devices keep running their local loops?”
- “If we need to replace the head-end in ten years, are the field devices going to keep working?”
A vendor who can answer these without hedging is the vendor whose proposal you can trust. A vendor who can’t is the vendor whose proposal is going to surprise you later.
This reference isn’t exhaustive — the field keeps inventing new acronyms. But the terms above cover most of what shows up on spec sheets and in vendor conversations. If you encounter something not on this list and you’re not sure what it means, it’s almost always worth asking the vendor directly. Building automation has enough genuine complexity that nobody benefits from anyone pretending to understand a term they don’t.