What is BACnet?
BACnet stands for Building Automation and Control Networks. It is a data communication protocol developed by ASHRAE (the American Society of Heating, Refrigerating and Air-Conditioning Engineers) and published as ASHRAE Standard 135, as well as ISO 16484-5 and IEC 62386-1 at the international level. First published in 1995, BACnet was specifically designed to address the interoperability problem in building automation: before BACnet, every building automation vendor used proprietary protocols, making multi-vendor systems expensive to integrate and creating long-term lock-in for building owners.
BACnet solves this by defining a vendor-neutral application layer that any manufacturer can implement. A thermostat from Siemens, a VAV controller from Johnson Controls, an energy meter from Schneider Electric, and a central building management system from Honeywell can all communicate using BACnet without any vendor-specific gateways between them — provided each device correctly implements the relevant parts of the standard.
BACnet is not just for HVAC. While BACnet is most heavily deployed in HVAC (heating, ventilation, and air conditioning) systems, the standard covers a broad range of building systems: lighting control, life safety (fire alarm and smoke detection), access control, security, energy metering, elevator control, and any other building system where equipment monitoring and control data needs to be shared across a network.
Why BACnet being an open standard matters
The practical significance of BACnet being an ASHRAE standard rather than a proprietary protocol is vendor neutrality across the full lifecycle of a building. Specifications can require BACnet compliance from all vendors without naming specific products. Replacements and upgrades can be sourced from any BACnet-compliant vendor rather than being locked to the original equipment manufacturer. Third-party monitoring, analytics, and building management systems can connect to any BACnet device without negotiating proprietary access.
This is what makes BACnet relevant to the kind of IT/OT convergence work that Software Toolbox does. Buildings — particularly large commercial and institutional facilities — are increasingly expected to expose their operational data to the same enterprise analytics, energy management, and fault detection platforms that process plant operational technology data flows into. BACnet is the protocol side of that access; OPC is typically the enterprise-side interface; and a BACnet-to-OPC bridge like TOP Server is what connects them.
BACnet network transports
BACnet defines a common application layer that runs over several different physical and network transports. The application layer — the objects, properties, and services described below — is the same regardless of the transport. The transport choice depends on the physical infrastructure available and the performance requirements of the application.
The BACnet object model: how BACnet represents data
The most distinctive feature of BACnet — what makes it fundamentally different from protocols like Modbus — is its object model. Rather than exposing data as raw registers or memory addresses, every piece of data in a BACnet device is represented as a named object with a standardized set of properties.
What is a BACnet object?
A BACnet object is a software representation of a data point or functional element within a BACnet device. Every object has a type (which defines what kind of data element it represents), an instance number (which uniquely identifies it within that object type on the device), and a set of properties (which carry the actual values and metadata). The combination of device instance, object type, and object instance uniquely identifies any data point on the entire BACnet network.
For example, a temperature sensor in a VAV controller might be represented as an Analog Input object with instance number 1. Its Present_Value property holds the current temperature reading; its Units property specifies degrees Celsius; its Description property carries the engineer-assigned description "Return Air Temp Zone 3A"; and its Out_Of_Service property indicates whether the physical input is active.
Standard BACnet object types
ASHRAE 135 defines a set of standard object types that all compliant devices are expected to use for representing their data. TOP Server's BACnet driver supports the following standard object types:
Key BACnet object properties
Every object type has a defined set of required and optional properties. The most important properties that TOP Server's driver exposes for the core data objects are:
| Property | Description | Typical data type |
|---|---|---|
| Present_Value | The current measured or commanded value of the object. The primary read/write point for most data objects. | REAL, BOOLEAN, UNSIGNED |
| Object_Identifier | Unique identifier combining object type and instance number. | BACnetObjectIdentifier |
| Object_Name | Human-readable name assigned by the device vendor or programmer. The basis for automatic tag naming in TOP Server. | CharacterString |
| Description | Optional longer description of the object's purpose. | CharacterString |
| Units | Engineering units for analog values (degrees C/F, percent, Pa, etc.) | BACnetEngineeringUnits |
| Status_Flags | Four bits: In_Alarm, Fault, Overridden, Out_Of_Service. The BACnet equivalent of an OPC quality stamp. | BACnetStatusFlags |
| Event_State | Whether the object is in a normal, fault, or alarm state. | BACnetEventState |
| Reliability | Indicates why a value may be unreliable — no input, communication failure, etc. | BACnetReliability |
| Out_Of_Service | When TRUE, the object's physical I/O is decoupled from Present_Value (used for testing). | BOOLEAN |
| Priority_Array | Array of 16 priority slots for writeable outputs. Supports Command Priority. | BACnetPriorityArray |
| COV_Increment | Minimum change in Present_Value that triggers a Change of Value notification. | REAL |
BACnet services: how devices communicate
BACnet defines a set of services that devices use to exchange data and initiate actions. Understanding the key services explains how TOP Server interacts with BACnet devices to read values, write setpoints, discover devices, and receive event notifications.
Read Property / Read Property Multiple
The foundational request-response services for reading object properties. ReadProperty reads a single property from a single object; ReadPropertyMultiple reads multiple properties from multiple objects in a single request. TOP Server uses ReadPropertyMultiple heavily — its "items per request" configuration (up to 64) controls how many object/property pairs are batched into each ReadPropertyMultiple request, directly affecting polling efficiency and network load.
Write Property
Writes a value to a specific property on a remote object. Write requests can include a priority level (1–16), which interacts with the Priority Array on commandable objects. TOP Server supports Command Priority, allowing writes to be submitted at a configurable priority level rather than defaulting to the minimum priority.
Who-Is / I-Am (Device Discovery)
Who-Is is a broadcast service that asks "which BACnet devices are on this network?" — either network-wide or to a specific device instance range. Devices respond with I-Am messages that carry their device instance number, vendor information, and maximum APDU size. TOP Server's BACnet driver uses Who-Is/I-Am for automatic device discovery — it can scan the network and automatically find all reachable BACnet devices without manual configuration of each device's IP address.
Subscribe COV / COV Notification (Change of Value)
Change of Value (COV) is BACnet's subscribe-and-push mechanism. Rather than polling a property repeatedly, a client sends a SubscribeCOV request to a device and the device sends COV notifications whenever the value changes by more than the configured COV_Increment. This eliminates polling overhead for stable values. TOP Server supports both Confirmed and Unconfirmed COV notifications.
Application Protocol Data Unit (APDU)
The APDU is the application-layer message container in BACnet — every service request, response, and notification is carried in an APDU. The maximum APDU size is negotiated between devices and determines whether messages need to be segmented across multiple packets. TOP Server provides configurable APDU settings that allow the maximum APDU size and segmentation parameters to be tuned to the specific network and device mix.
Confirmed vs. Unconfirmed COV: Confirmed COV notifications require the receiving device to send an acknowledgment back to the producer — adding reliability at the cost of a round-trip for each notification. Unconfirmed COV notifications are fire-and-forget: faster and lower overhead, but with no guarantee of delivery. TOP Server supports both modes; the choice depends on the reliability requirements of the application and the performance characteristics of the BACnet network.
PICS and BIBBs: how BACnet defines conformance
BACnet is a large standard — no single device is expected to implement all of it. The standard defines a conformance framework based on two key concepts: Protocol Implementation Conformance Statements (PICS) and BACnet Interoperability Building Blocks (BIBBs).
PICS (Protocol Implementation Conformance Statement)
A PICS is a document that a BACnet device vendor must provide, stating exactly which parts of the BACnet standard the device implements. It lists supported object types, supported properties for each object type, supported services, and any vendor extensions. Before purchasing or integrating a BACnet device with TOP Server, reviewing its PICS confirms whether the objects, properties, and services that TOP Server's driver uses are actually supported by that specific device and firmware version.
BIBBs (BACnet Interoperability Building Blocks)
A BIBB is a named set of services and objects that together enable a specific interoperability function. Rather than specifying that a device supports individual services, BIBBs package them into functional units. For example, Data Sharing – ReadProperty-B (DS-RP-B) is the BIBB for a device that can respond to ReadProperty requests. TOP Server's BACnet driver has a specific list of BIBBs it requires from devices for different features — devices must implement the corresponding BIBBs for those features to work.
BACnet device compatibility: Not every BACnet device will work with every BACnet client software. Compatibility depends on whether the device's PICS covers the objects, properties, and services the client uses. Software Toolbox maintains a detailed BACnet Device Compatibility article covering the BIBBs supported by TOP Server's BACnet driver. Consult this resource before deploying TOP Server against a specific BACnet device.
BACnet vs. OPC: complementary, not competing
Engineers sometimes ask whether BACnet replaces OPC or competes with it. They serve different layers of the architecture and are almost always used together in building-to-enterprise integration projects.
| Dimension | BACnet | OPC (DA / UA) |
|---|---|---|
| Primary purpose | Device-to-device communication within a building automation system | Device/system data exposure to SCADA, historians, analytics, and enterprise applications |
| Domain | Building automation: HVAC, lighting, life safety, access control | Universal industrial and building automation; vendor-neutral enterprise integration |
| Information model | Yes — rich object model with typed objects, named properties, engineering units | Yes (UA) — semantic nodes, types, relationships; OPC DA is flat tag/value |
| Built-in security | Limited — BACnet/SC adds TLS; base BACnet has minimal security | Yes (UA) — X.509 certificates, TLS, role-based access |
| Alarm / event model | Yes — intrinsic alarming, algorithmic change detection, COV notifications | Yes (A&E / UA) — OPC A&E and OPC UA alarms & conditions |
| Historical data | Yes — Trend Log objects, SubscribeCOVProperty | Yes (HDA / UA) — OPC HDA and OPC UA Historical Access |
| Typical consumers | Building management systems, building controllers, DDC systems | SCADA, historians (OSIsoft PI, AVEVA), MES, ERP, cloud analytics, AI platforms |
| IT network compatibility | BACnet/IP runs on standard Ethernet; MS/TP requires serial infrastructure | Yes — TCP/IP, runs on standard IT network infrastructure |
In practice, the integration architecture for most building-to-enterprise data flows uses BACnet at the device layer, TOP Server as the BACnet-to-OPC bridge, and OPC UA for the enterprise-side interface to historians, SCADA, analytics, and cloud platforms.
How TOP Server connects to BACnet devices
TOP Server's BACnet Ethernet driver provides OPC DA, OPC UA, and SuiteLink connectivity to BACnet/IP (Annex J) devices on Ethernet networks, and to non-Ethernet BACnet devices (MS/TP, ARCNET, LonTalk) through BACnet/IP gateways. Here are the key capabilities of the driver:
The driver sends Who-Is broadcasts to discover all BACnet devices on the network. Discovered devices can be mass-added to the configuration with a single operation. Each device added from discovery automatically inherits the discovered device name from its I-Am response.
Once devices are discovered, the driver can interrogate each device's object list and generate OPC tags automatically — one tag per object property, organized into configurable groups. This eliminates the need to manually enter BACnet object instance numbers and property identifiers for each data point.
TOP Server subscribes to Change of Value notifications from BACnet devices rather than polling every tag at a fixed rate. Values are updated when they change by more than the COV_Increment — reducing network traffic significantly for stable values. Supports both Confirmed and Unconfirmed COV.
BACnet commandable objects use a 16-level priority array for write commands. A write at priority 8 can be overridden by a later write at priority 1, without canceling the priority-8 command. TOP Server supports configuring the write priority for commands, enabling correct integration with BAS systems.
TOP Server connects to MS/TP serial devices, ARCNET devices, LonTalk devices, and other non-Ethernet BACnet networks through BACnet/IP-to-serial gateways and BACnet routers. The driver also supports registration as a foreign device on the BACnet network when required.
BACnet APDU settings affect message segmentation and performance. TOP Server allows the maximum APDU size and segmentation window to be configured per channel. Configurable items-per-request (up to 64 per ReadPropertyMultiple request) allows network traffic to be optimized.
Frequently asked questions
Ready to connect your BACnet devices to OPC?
TOP Server's BACnet Ethernet driver supports automatic device discovery, COV subscriptions, all standard BACnet object types, and gateway-based access to MS/TP and other non-Ethernet BACnet networks. Talk to an engineer about your specific devices.