In modern building automation, interoperability is key. Systems for HVAC, lighting, security, or energy management often come from different vendors, yet they must all “speak the same language.” This is where BACnet has become a global standard.
At the heart of BACnet lies a powerful concept: the object model. Instead of exchanging raw or proprietary data, BACnet represents every element—whether it’s a temperature sensor, a fan, or a weekly schedule—as a standardized object with defined properties and accessible through services.
“The genius of the BACnet object model is that it abstracts every device into a standardized object, making complex building systems interoperable.“
This article explores how the BACnet object model works, why it is central to interoperability, and how it helps building owners and integrators simplify complex projects. For general background, you may first want to read What is BACnet?
The BACnet object model is the foundation that makes the protocol both powerful and universal. Instead of handling data points in a proprietary way, BACnet represents every element of a building automation system as an object.
An object is not just a value — it’s a complete structure with:
This approach ensures that a temperature sensor from Vendor A can be read by a building management system from Vendor B without custom integration.
| Object Type | Typical Use Case |
|---|---|
| Analog Input | Temperature sensor measurement |
| Binary Output | Fan ON/OFF command |
| Schedule | Weekly HVAC operating program |
| Trend Log | Recording energy consumption |
| Device | The controller itself |
The BACnet object model is built around a few simple but powerful principles:
| Element | Purpose |
|---|---|
| Object Identifier | Unique numeric ID (type + instance), used in network communication |
| Object Name | Human-friendly label, unique inside a device |
| Object Type | Defines the object’s role (AI, BO, Schedule, Trend Log, etc.) |
Every BACnet object is defined by a set of properties. These properties describe the object’s state, behavior, and metadata. They are what makes BACnet devices interoperable, since all vendors agree on a minimum set of mandatory properties while leaving room for optional ones.
Types of properties
| Property type | Example property | Purpose |
|---|---|---|
| Mandatory | Object Identifier | Ensures uniqueness and identification across devices |
| Optional | Description | Adds human-readable information for operators |
| Dynamic (runtime) | Present Value | Represents the real-time measurement or command state |
| Optional | Units | Defines engineering units (°C, Pa, %, ppm, kWh, etc.) |
| Mandatory | Object Type | Defines category of the object (AI, BO, Schedule…) |
In building automation, several systems may want to control the same point — for example, a fan could be commanded by the fire safety system, by an energy optimization algorithm, or by a manual operator. To avoid conflicts, BACnet uses a Priority Array system.
How it works
| Mechanism | Practical effect |
|---|---|
| Priority Array (1–16) | Resolves conflicts by applying the highest active priority |
| Relinquish Default | Provides a fallback when no priorities are active |
| WriteProperty | Writes a value at a specific priority level |
| WritePropertyMultiple | Allows batch writes for consistency across multiple objects |
BACnet objects become truly useful when other devices and software can interact with them. This interaction happens through BACnet services, which are standardized operations defined by the protocol. Services allow systems to read values, write commands, discover devices, or subscribe to updates.
Without services, the object model would just be a static description. With them, it becomes a dynamic framework for real-time automation.
| Service | Typical use case |
|---|---|
| ReadProperty | Retrieve the value of a single property (e.g., Present Value) |
| ReadPropertyMultiple | Read several properties at once to reduce traffic |
| WriteProperty | Write a command or update a configuration value |
| WritePropertyMultiple | Write to several properties in one operation |
| SubscribeCOV | Subscribe to updates when a property changes (instead of polling) |
| Who-Is / I-Am | Discover devices on the network and identify them |
| Who-Has / I-Have | Find objects by name across devices |
💡 With these services, building management systems can automatically discover devices, configure them, monitor real-time values, and ensure smooth multi-vendor interoperability. For a complete overview of network exchanges, discovery and services, see How does BACnet work?
Beyond simple sensors and actuators, the BACnet object model also supports objects that define behavior and historical data. These higher-level objects are essential for building automation strategies such as energy optimization, predictive maintenance, and comfort scheduling.
| Object | Benefit |
|---|---|
| Schedule | Automates recurring operations locally, reducing manual intervention and network load |
| Calendar | Centralizes exceptions (holidays, maintenance days) for easier management |
| Trend Log | Provides historical data for diagnostics, energy efficiency tracking, and reporting |
These objects turn BACnet from a simple communication protocol into a complete framework for automation and optimization.
While the BACnet object model defines how devices represent data, interoperability also requires that devices declare what they are capable of doing. This is achieved through formal profiles and documentation.
These profiles ensure that two BACnet devices from different vendors can be matched for compatibility before deployment.
| Artifact | Role |
|---|---|
| BIBBs | Define functional building blocks for interoperability |
| PICS | Vendor’s declaration of supported objects and services |
| EPICS | Extended statement for complex devices/integrations |
💡 Thanks to these standardized profiles, system integrators can verify interoperability upfront, avoiding costly surprises during commissioning.
To illustrate how the BACnet object model works in practice, let’s take a rooftop unit (RTU) used for HVAC. This single piece of equipment includes multiple functions, each represented as a BACnet object.
Example: Supply Air Temperature
Purpose: Monitors delivered air temperature
Example: Fan Speed Command
Purpose: Controls variable fan speed (%)
Example: Filter Alarm
Purpose: Detects clogged filter condition
Example: Compressor Enable
Purpose: Turns the compressor ON/OFF
Example: Operating Mode (Auto/Heat/Cool/Off)
Purpose: Selects unit operating mode
Example: Occupancy Program
Purpose: Runs HVAC only during building use
Example: Energy Consumption (kWh)
Purpose: Records historical energy usage
This example shows how the BACnet object model enables clear structuring, deterministic control, and vendor-independent interoperability.
The BACnet object model is not just a technical abstraction — it has direct business and operational benefits for building owners, facility managers, and system integrators.
| Benefit | Impact |
|---|---|
| Standardization | Faster integration, lower engineering costs |
| Transparency | Easier diagnostics, reliable documentation |
| Determinism | Safe multi-system control without conflicts |
| Efficiency | Reduced traffic, automated tasks, better insights |
| Future-proofing | Avoids vendor lock-in, scalable over time |
It’s a standardized way to represent every building function as an object with properties and services, so devices from different vendors can communicate seamlessly.
Objects package the value with metadata (units, status, priority) and define how it can be accessed, which ensures consistency across systems.
Yes. While object types are standardized, vendors can extend them with optional properties or create proprietary objects when needed.
Mandatory properties guarantee basic interoperability. Optional properties provide added functionality but are not required for compatibility.
Services like ReadProperty and WriteProperty allow systems to read or write values, while SubscribeCOV lets them get updates when values change.
Yes. It was designed to ensure vendor independence, meaning equipment from different manufacturers can work together without custom drivers.
Objects like Trend Logs and Schedules make it easy to monitor consumption, automate operation times, and optimize system performance for energy savings.
About Actility
Actility, one of the co-inventors of LoRaWAN® technology and a founding member of the LoRa Alliance, is the leader in industrial-grade low-power wide-area network (LPWAN) connectivity and IoT tracking solutions. Actility’s ThingPark™ platform, which supports multi-radio connectivity (LoRaWAN®, NB-IoT, LTE-M), powers the majority of public networks and numerous private and enterprise networks worldwide. Through its subsidiary Abeeway, Actility offers patented ultra-low power, multi-radio trackers and comprehensive indoor and outdoor geolocation services. Additionally, the ThingPark Market boast the largest catalog of LoRaWAN® devices, gateways, and solutions available.
Media contact : marketing@actility.com – https://www.actility.com/contact/
© 2024 Actility’s All Rights Reserved