BACnet Services BACnet
BACnet Basics named the five services that carry almost every everyday read, write, and notification, then moved on. This page is the fuller reference: what a service actually is, the confirmed / unconfirmed split, the service families, and — the part that decides whether two devices will actually talk — BIBBs and device profiles. If objects are the nouns of BACnet and properties the adjectives, services are the verbs; and a device only speaks the verbs its conformance claims, which is what the second half of this page is about.
What a service is
A service is a defined request-and-response message against the object model — the thing a client puts on the wire to read a property, write one, acknowledge an alarm, or subscribe to a change. One device initiates the service (the client); another executes it (the server). The same physical box is usually both: a controller is a server when a workstation reads it, and a client when it reads a sensor down the trunk. ASHRAE 135 defines roughly three dozen services; a handful do almost all the work.
The first split to internalize is confirmed vs. unconfirmed. A confirmed service expects an answer: the initiator sends the request and waits, and the executor returns either an acknowledgement (carrying any result) or a BACnet-Error. ReadProperty and WriteProperty are confirmed — you always learn whether they worked. An unconfirmed service is fire-and-forget: it is sent, usually as a broadcast, and no reply is owed. Discovery (Who-Is / I-Am) and time synchronization live here — even I-Am, the "reply" to Who-Is, is itself an unconfirmed broadcast, not an acknowledgement.
The service families
The standard groups services into interoperability areas — Data Sharing, Alarm & Event, Scheduling, Trending, and Device & Network Management. You will meet the Data Sharing ones daily; the rest show up when a specific feature does. The table is the field-relevant set, not the full three dozen.
| Service | Type | Area | What it does |
|---|---|---|---|
ReadProperty | Confirmed | Data Sharing | Fetch one property of one object — the everyday read. |
ReadPropertyMultiple | Confirmed | Data Sharing | Fetch many properties across many objects in one request — how a graphic polls a controller. |
WriteProperty | Confirmed | Data Sharing | Set one property — often a priority-array write on a commandable point. |
WritePropertyMultiple | Confirmed | Data Sharing | Set many properties in one request. |
SubscribeCOV | Confirmed | Data Sharing | Ask a device to push a notification whenever a value changes past its COV_Increment — instead of polling. |
ConfirmedCOVNotification | Confirmed | Data Sharing | The push itself, when the subscription asked for an acknowledged delivery. |
UnconfirmedCOVNotification | Unconfirmed | Data Sharing | The same push with no acknowledgement — lighter, but it can be missed. |
ConfirmedEventNotification | Confirmed | Alarm & Event | Deliver an alarm or event to a recipient that must acknowledge receipt. |
UnconfirmedEventNotification | Unconfirmed | Alarm & Event | Deliver an alarm or event with no delivery acknowledgement. |
AcknowledgeAlarm | Confirmed | Alarm & Event | An operator acknowledges an alarm — the "ACK" the workstation sends back. |
GetEventInformation | Confirmed | Alarm & Event | Pull the list of objects currently in an active or unacknowledged event state. |
Who-Is / I-Am | Unconfirmed | Device Mgmt | Discovery — "who is out there?" and "here I am, device 1001." Both are broadcasts. |
Who-Has / I-Have | Unconfirmed | Device Mgmt | Find which device holds a named or numbered object. |
ReinitializeDevice | Confirmed | Device Mgmt | Warm- or cold-start a device — password-protected. |
DeviceCommunicationControl | Confirmed | Device Mgmt | Silence or re-enable a device's communication — password-protected; a classic "why did half the trunk go quiet" cause. |
TimeSynchronization / UTC… | Unconfirmed | Device Mgmt | Broadcast the current time (local or UTC) to the network. |
AtomicReadFile / …WriteFile | Confirmed | Data Sharing | Read or write a File object in chunks — firmware, trend uploads, config. |
CreateObject / DeleteObject | Confirmed | Object Access | Make or remove an object at runtime — how a controller with dynamic objects is provisioned. |
Two habits carry the everyday work. First, the …Multiple variants exist so a client can read or write a graphic's worth of points in one round trip instead of thirty — a device that only supports the singular forms will still work, just slower and noisier on the wire. Second, COV (change-of-value) is BACnet's answer to Modbus-style polling: subscribe once and be told when the value moves, rather than asking again and again. Whether a given device can actually do either of those is not a given — which is the whole point of the next section.
BIBBs — what a device actually supports
"It's BACnet" does not mean "it does everything." A tiny unit controller might answer ReadProperty and nothing else; a supervisor might initiate every service in the book. The unit that captures which capabilities a device claims is the BIBB — a BACnet Interoperability Building Block. Each BIBB pairs one service with one role, and its name is three parts: the interoperability area, the service, and an A or B.
The role letter is the piece people get backwards. A is the client — the device that initiates the service (the requester). B is the server — the device that executes it (the responder). The mnemonic: A comes before B as a request comes before a response. So a controller that can be read advertises DS-RP-B (it answers ReadProperty); the workstation reading it needs DS-RP-A (it initiates ReadProperty). A device that has to both serve and initiate a service claims both halves.
The interoperability-area codes are short: DS Data Sharing, AE Alarm & Event, SCHED Scheduling, T Trending, DM Device Management, NM Network Management. The common BIBBs a controls spec sheet lists:
| BIBB | Service | A / B roles |
|---|---|---|
DS-RP-A / -B | ReadProperty | A reads · B is read |
DS-RPM-A / -B | ReadPropertyMultiple | A reads many · B answers |
DS-WP-A / -B | WriteProperty | A writes · B is written |
DS-WPM-A / -B | WritePropertyMultiple | A writes many · B accepts |
DS-COV-A / -B | Subscribed change-of-value | A subscribes · B notifies |
DS-COVU-A / -B | Unsubscribed COV | A receives · B broadcasts |
AE-N-A / -B | Event / alarm notification | A is notified · B notifies |
AE-ACK-A / -B | Alarm acknowledgement | A acknowledges · B tracks |
DM-DDB-A / -B | Dynamic Device Binding — Who-Is / I-Am | A discovers · B answers |
DM-DOB-A / -B | Dynamic Object Binding — Who-Has / I-Have | A discovers · B answers |
DM-RD-A / -B | ReinitializeDevice | A commands · B restarts |
DM-DCC-A / -B | DeviceCommunicationControl | A commands · B obeys |
DM-TS-A / -B, DM-UTC-… | Time synchronization | A sends time · B sets its clock |
This is why two "fully BACnet" devices can still fail to do what you need. A workstation that wants live updates needs DS-COV-A, and the field controller needs DS-COV-B — if the controller only has DS-RP-B, you are polling whether you like it or not. Reading the BIBB lists on both sides tells you, before you wire anything, whether the integration you are quoting is actually possible.
Device profiles and the PICS
Listing BIBBs one by one would be tedious, so the standard bundles them into device profiles — a named minimum set a device promises to meet. The profile is shorthand: say "B-BC" and another engineer knows roughly what the box can do. The common ones on a controls job:
| Profile | Device | Typically |
|---|---|---|
B-BC | Building Controller | A programmable supervisory controller — a JACE, a plant controller. Rich BIBB set, acts as client and server. |
B-AAC | Advanced Application Controller | Runs advanced but fixed programs; more capable than a B-ASC, not fully field-programmable over BACnet. |
B-ASC | Application Specific Controller | A fixed-function unit controller — a VAV box, a fan-coil. Mostly a server; the smaller BIBB set. |
B-SA | Smart Actuator | A commandable actuator that answers reads and writes. |
B-SS | Smart Sensor | Reports a value; a small server, often read-only. |
B-OWS | Operator Workstation | The front end / BMS — a heavy client that initiates reads, writes, subscriptions, and alarm acknowledgements. |
B-GW | Gateway | Bridges BACnet to another protocol; what it exposes depends on the far side. |
Where a profile is the label, the PICS is the fine print. A PICS — Protocol Implementation Conformance Statement — is the document every vendor publishes for a device: its profile, its exact BIBB list, the object types it supports, whether it does segmentation, its character sets, and its data-link options. When a device "should" do something and doesn't, the PICS is where you confirm whether it ever could. It is the single most useful page in a BACnet device's manual, and most techs never open it.
The profile also sets expectations for the object model behind it: a B-BC will carry the full commandable object set and a priority array on its outputs, while a B-SS may expose a single Analog Input and little else. Pair the profile with the object reference and you can predict most of a device's point list before it is even on the network.
What this page didn't cover
Out of scope here, by design: the full BIBB catalog (well over a hundred, most of them Scheduling, Trending, Network Management, and BACnet/SC blocks a controls tech rarely specifies), the deep mechanics of alarms and event notification — Notification_Class objects, event states, and the recipient list — which are their own topic, and segmentation, the machinery that splits a service response too big for one APDU, worth its own treatment. How these messages cross a router and a broadcast domain is BACnet Networking; the object model the services act on is BACnet Basics; and the numbers a device sends back when a service fails are in the Error Code Decoder.