The BACnet Object and Property Model

Back to Blog

What an Object Represents

A BACnet object is a software representation of one thing the device measures, controls, or manages. A temperature sensor input becomes an Analog Input object; a controllable damper becomes an Analog Output or a Binary Output; a running total from a meter becomes an Accumulator. The standard defines a catalogue of object types, and each type has an agreed meaning, so a client that finds an Analog Value object in one vendor's controller and another vendor's controller can treat both the same way. This is the heart of BACnet interoperability, and it is a deliberate contrast with a protocol like Modbus, where a register number carries no built-in meaning at all.

Objects are not limited to physical points. Alongside inputs and outputs there are objects for data structures the controller manages internally: a Schedule object that turns points on and off by time of day, a Calendar object that lists special dates, a Trend Log object that records a point's history, a Notification Class object that routes alarms. Treating these as objects, with the same read and write mechanics as a sensor value, is what lets a supervisory client configure a controller's scheduling or alarming remotely without a proprietary tool. Each of these object types has its own dedicated reference in this cluster.

Every object on a device is addressed by an Object_Identifier, which combines the object type and an instance number - Analog Input 3, Binary Output 12. That identifier is how a client names the object it wants to read or write. The type half tells the client how to interpret the object; the instance half distinguishes it from every other object of that type on the same device. The identifier and the property model together mean a client can locate and interpret any point on a device it has only just discovered.

What a Property Is and Which Ones Are Required

A property is a named, typed attribute of an object. The Present_Value property holds the object's current value - the measured temperature, the commanded output, the run status. Object_Name holds a human-readable label. Units holds the engineering unit for an analog value. Status_Flags holds the four fault and alarm bits that tell a client whether the value is trustworthy. Each property has a defined data type and a defined meaning, so a client reading Units on any Analog Input knows it will get an enumerated engineering unit, not a free-form string.

The standard marks each property of each object type as required, optional, or writable. Required properties must exist on every object of that type, which is what guarantees a client can rely on finding Present_Value, Object_Name, Object_Type, and Status_Flags on any input or value object. Optional properties may or may not be present depending on the device and how rich the vendor made it. Writable properties are the ones a client may change - the Present_Value of an output object, the schedule entries of a Schedule object. Reading a device's Property_List, where supported, tells a client exactly which properties a given object actually carries.

Because the required-property set is fixed per object type, integration becomes a browse-and-map exercise rather than a decode exercise. A client walks the device's object list, reads Object_Name and Present_Value for each object, and has a working point list. This is why bringing BACnet points into a tag database or a SCADA tag structure is usually more straightforward than mapping a register-based device, where the same work requires an externally supplied register map to give the numbers meaning.

How the Model Shapes Integration and Monitoring

When a supervisory system or gateway reads a BACnet controller, it is really reading properties of objects. A poll for a room temperature is a request for the Present_Value property of a specific Analog Input object; a command to a damper is a write to the Present_Value of an Analog Output object at a chosen priority. Understanding that every interaction is a property access on a named object is what makes the rest of BACnet - the services that do the reading and writing, described in the ReadProperty service reference - fall into place.

The self-describing nature of the model also shapes how a value should be trusted. A Present_Value never travels alone in a well-designed integration: its Status_Flags and Reliability properties say whether the value is currently valid, in fault, or in alarm. A client that maps only Present_Value and ignores the status properties will happily record a stale or faulted number as if it were good. Reading the status alongside the value is a small amount of extra work that turns a raw number into a trustworthy one, which matters as much for a facility HVAC point as for a process measurement.

For unified monitoring, the object model is what lets facility data sit naturally beside process telemetry. A cloud SCADA such as Merobix that browses a BACnet device's objects can map each Present_Value into a tag, carry its units and status, and trend it in the same historian as everything else. The point mapping is durable because the object identifiers are stable on the device, so once the objects are mapped the integration does not depend on rediscovering them - the same principle covered in the BACnet discovery guide.

Frequently Asked Questions