BACnet (Building Automation and Control networks) is an international standard (ISO 16484-6) developed by ASHRAE, designed to facilitate communication between different building automation and control systems. By providing a standardized language, it allows devices from various manufacturers to interoperate seamlessly โ which is essential for energy-efficient building management.
What is BACnet? An open protocol that lets controllers, sensors, and software from different manufacturers talk to each other โ no proprietary drivers needed.
Core Concepts of BACnet
1. The BACnet Device
Every BACnet-compliant system consists of Devices. A device is essentially a physical or logical entity on the network โ for example, a thermostat, a lighting controller, or an air handling unit (AHU) controller. Every device is represented by a single Device Object, which must have a unique identifier across the entire BACnet internetwork.
2. Objects: The Building Blocks of Data
BACnet uses an object-oriented approach to represent data. Instead of raw memory addresses, it organizes information into "objects" that define what the data is and how it behaves. Standard object types include:
- Analog Input / Output (AI/AO): Represents sensors or actuators with continuous values, such as temperature readings.
- Binary Input / Output (BI/BO): Represents on/off or digital states, such as switch or valve status.
- Analog / Binary Value: Used for software-based setpoints or parameters.
- Trend Log / Schedule: Specialized objects for time-based data or historical recording.
3. Properties and Instances
Every object contains a set of Properties โ such as Present_Value, Object_Name, and Reliability โ that describe its current state.
Within a device, each object is uniquely identified by an Object Type combined with an Instance Number. For example, two temperature sensors in the same device might be identified as Analog Input 1 and Analog Input 2. This combination must be unique within that specific device.
Example: Analog Input 1 โ Object_Name: Zone Temp 1 | Present_Value: 72.5ยฐF | Reliability: No Fault
Network Communication
BACnet does not rely on a single physical medium. Instead, it defines a standard "application layer" that can operate over various networking technologies.
Data Representation
When a system requests data, it asks for specific properties of a specific object within a specific device. Because the objects are "network-visible," the requesting device does not need to know the controller's internal programming or hardware layout โ it simply interacts with the object.
Interoperability
Because the BACnet standard defines exactly how objects and properties must behave, a third-party software system can read an Analog Input from a controller made by Manufacturer A and write to an Analog Output on a controller made by Manufacturer B โ without needing proprietary drivers for each.
BACnet/IP
For modern building networks, BACnet is frequently encapsulated within IP (Internet Protocol) frames. This allows BACnet messages to traverse standard enterprise Ethernet and Wi-Fi infrastructure, often requiring specialized routers or Packet-Assembler-Disassemblers (PADs) to connect different physical subnets.
Summary Table
| Concept | Description |
|---|---|
| Device | A unique, network-accessible controller with a globally unique Device Instance Number. |
| Object | A standardized way to represent a piece of data โ sensor reading, actuator command, setpoint, etc. |
| Instance | A unique number assigned to an object type within a device to distinguish it from others of the same type. |
| Property | Attributes of an object (e.g., Present_Value, Object_Name) that define and describe its current state. |
References
Bushby, S. T. (1997). BACnetโข: a standard communication infrastructure for intelligent buildings. Automation in Construction, 6(5โ6), 529โ540. doi.org/10.1016/s0926-5805(97)00029-0
Newman, H. M. (2013). BACnetยฎ Explained. BACnet.org. bacnet.org
Ulmer, R., & Mรผller, J. (2019). User-oriented verification of automation stations. E3S Web of Conferences, 111, 05024. doi.org/10.1051/e3sconf/201911105024