What Is the BACnet Object Identifier?
Every object on a BACnet device has to be addressable, and the Object_Identifier is how it is addressed. It is a compact value that fuses two facts - what kind of object this is and which one - into a single reference a client uses to read or write it. This reference explains how the identifier is built from an object type and an instance number, why the Device object's identifier doubles as the device's own address, and how this addressing scheme underpins discovery and routing across a BACnet internetwork.
BACnet Object Identifier in one line: A BACnet Object_Identifier combines an object type and an instance number into one value that uniquely names an object within its device - for example Analog Input instance 3, or Binary Output instance 12. The type half tells a client how to interpret the object; the instance half distinguishes it from other objects of that type. The Device object's identifier carries the device instance number, which must be unique across the whole BACnet internetwork.
Type Plus Instance in One Value
The Object_Identifier encodes two pieces of information together. The first is the object type - Analog Input, Binary Output, Schedule, Trend Log, and so on - drawn from the standard's enumerated list of types. The second is the instance number, which distinguishes objects of the same type on the same device. So Analog Input 0, Analog Input 1, and Analog Input 2 are three different sensors, while Analog Input 0 and Binary Input 0 are unrelated objects that share an instance number but differ in type. The identifier only has meaning as the type and instance together, exactly as a DNP3 point needs both its object group and its index.
This structure means instance numbers restart per type. A device can hold Analog Inputs 0 through 40 and Binary Inputs 0 through 40 at the same time, and there is no conflict, because the type disambiguates them. When a client wants a specific point it names the full identifier - the type and the instance - and the device returns exactly that object. Reading a raw instance number without its type is therefore ambiguous, which is why point documentation for a BACnet device always records the object type alongside the instance.
Because the identifier is a single value, it travels compactly in every service request. A ReadProperty request names the Object_Identifier of the object it wants and the property it wants from that object. The device parses the type and instance out of the identifier, locates the object, and returns the property. This is the addressing mechanism behind every read and write, and understanding it makes the object and property model concrete: an object is reached by its identifier, and a value is reached by naming a property of that object.
The Device Object Identifier as the Device Address
Every BACnet device has exactly one Device object, and that object's identifier is special: its instance number is the device instance number, the address by which the whole device is known on the internetwork. When a client discovers devices with a Who-Is broadcast, the I-Am responses it receives carry each device's Device object identifier, which is how the client learns which device instances are present. So the Device object's instance number is not just one object's address among many - it is the identity of the device itself.
This is why device instance numbering is a planning matter, not an afterthought. The device instance must be unique across the entire BACnet internetwork, not merely unique on one segment, because a client anywhere on the internetwork addresses a device by that number. Two devices sharing an instance number cause responses that confuse clients and devices that appear and vanish, a failure explored in the device instance numbering guide. The object identifier scheme is what makes a coherent numbering plan essential rather than optional.
The device instance also anchors how a value is fully addressed across a network. A specific point in a large system is identified by the device instance plus the object identifier within that device - device 200401, Analog Input 3, for example. The device instance locates the controller; the object identifier locates the point inside it. That two-level addressing is what lets a supervisory client reach any point on any device across a routed BACnet internetwork, provided the routing and, where subnets are crossed, the broadcast infrastructure described in the BBMD reference are in place.
Frequently Asked Questions
What two things make up a BACnet Object Identifier?
An object type and an instance number, fused into one value. The type - such as Analog Input, Binary Output, or Schedule - tells a client how to interpret the object. The instance number distinguishes objects of that same type on the same device. The identifier is meaningful only as the pair, so Analog Input 3 and Binary Output 3 are entirely different objects that happen to share an instance number.
Why does every BACnet object instance number restart per type?
Because the object type is part of the identifier, so instance numbers only need to be unique within a type. A device can hold Analog Inputs 0 to 40 and Binary Inputs 0 to 40 simultaneously with no conflict, since the type disambiguates them. That is why point documentation always records the object type alongside the instance number - the instance alone is ambiguous without it.
What is the device instance number in the Object Identifier?
It is the instance number of the device's single Device object, and it doubles as the whole device's address on the BACnet internetwork. Who-Is discovery returns each device's Device object identifier, so clients learn devices by this number. It must be unique across the entire internetwork, not just one segment, because clients anywhere address a device by its device instance.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Overview of DNP3 (IEEE Std 1815) - DNP Users Group
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.