What B-BC Is
A BACnet device profile is a standardized capability level: a checklist of things a device must be able to do before it can wear the label. B-BC (BACnet Building Controller) is the flagship controller profile, defined in Annex L of ANSI/ASHRAE 135-2024 (clause L.4.1) as a general-purpose, field-programmable device capable of carrying out a variety of building automation and control tasks. Of the controller profiles, B-BC carries the heaviest requirement set: it must share data in both directions, generate and manage alarms, schedule actions in itself and in other devices, collect trend data, and support backup and restore.
The checklist items are BACnet Interoperability Building Blocks (BIBBs), each a named unit of capability such as “can answer read requests” (DS-RP-B). A device claims a profile by implementing every BIBB the profile requires, and documents the claim in its PICS (Protocol Implementation Conformance Statement). Specifiers use profile codes as shorthand in tender documents: writing “B-BC” into a specification demands the full capability set below without listing every individual service. To verify a vendor’s claim, ask for the PICS and check the profile line.
Where It’s Used
B-BC devices sit at the top of the controller tier: the programmable panel in the mechanical room rather than the terminal-unit controller above the ceiling.
- Central plant controllers. A hospital’s chiller-plant controller sequencing chillers, pumps, and towers, while serving trend data to the BMS and writing setpoints to downstream equipment.
- Supervisory field controllers. A school district’s per-building controller that runs the schedules, aggregates alarms from application-specific controllers, and keeps operating through an outage of the head end (the central BMS server).
- Plant automation controllers. A manufacturing site’s air-handler plant controller that both serves its own points and pulls values from other devices to run its sequences.
Required Services
The table below is the exhaustive service set required by the B-BC BIBBs. Initiates means the device sends the request or notification; Executes means the device receives and acts on it (responding, for confirmed services). BIBB codes encode the same split: a -A BIBB is the initiating side, a -B BIBB the executing side. A - means the profile does not require that direction; a device may still support it. A service can appear under two capability areas when two different BIBBs use it.
| Capability area | Service | Required by BIBB | Initiates | Executes |
|---|---|---|---|---|
| Data sharing | ReadProperty | DS-RP-A, DS-RP-B | Yes | Yes |
| Data sharing | ReadPropertyMultiple | DS-RPM-A, DS-RPM-B | Yes | Yes |
| Data sharing | WriteProperty | DS-WP-A, DS-WP-B | Yes | Yes |
| Data sharing | WritePropertyMultiple | DS-WPM-B | - | Yes |
| Alarm and event management | ConfirmedEventNotification | AE-N-I-B | Yes | - |
| Alarm and event management | UnconfirmedEventNotification | AE-N-I-B | Yes | - |
| Alarm and event management | AcknowledgeAlarm | AE-ACK-B | - | Yes |
| Alarm and event management | GetEventInformation | AE-INFO-B | - | Yes |
| Alarm and event management | GetEnrollmentSummary ¹ | AE-ESUM-B | - | Yes |
| Alarm and event management | WriteProperty (recipient-list configuration) ² | AE-CRL-B | - | Yes |
| Scheduling | WriteProperty (schedule write-out to other devices) | SCHED-E-B | Yes | - |
| Trending | ReadRange | T-VMT-I-B | - | Yes |
| Trending | ConfirmedEventNotification (buffer-ready) | T-ATR-B | Yes | - |
| Device and network management | Who-Is | DM-DDB-A, DM-DDB-B | Yes | Yes |
| Device and network management | I-Am | DM-DDB-A, DM-DDB-B | Yes | Yes |
| Device and network management | Who-Has | DM-DOB-B | - | Yes |
| Device and network management | I-Have | DM-DOB-B | Yes | - |
| Device and network management | DeviceCommunicationControl | DM-DCC-B | - | Yes |
| Device and network management | TimeSynchronization ³ | DM-TS-B | - | Yes |
| Device and network management | UTCTimeSynchronization ³ | DM-UTC-B | - | Yes |
| Device and network management | ReinitializeDevice | DM-RD-B, DM-BR-B | - | Yes |
| Device and network management | AtomicReadFile (backup) | DM-BR-B | - | Yes |
| Device and network management | AtomicWriteFile (restore) | DM-BR-B | - | Yes |
The services are only half the checklist. The scheduling and trending rows also require the device to host working Schedule, Calendar, and Trend Log objects, and the alarm rows require Notification Class objects with writable recipient lists. One notable absence: B-BC does not require COV subscription support, so do not assume a B-BC device serves COV without checking its PICS.
¹ Not required of devices at protocol revision 13 or later. (Protocol_Revision is a readable property of the device’s Device object.)
² AE-CRL-B is required only of devices at protocol revision 19 or later. The recipient lists must be writable with WriteProperty; list-manipulation services are optional.
³ The profile requires one of the two time-synchronization services, not both.
Related Profiles
| Profile | How it differs from B-BC |
|---|---|
| B-AAC | Advanced Application Controller: one step down. Internal scheduling only, no trending requirement, no backup-and-restore |
| B-ASC | Application Specific Controller: fixed-function, serves and accepts writes but has no alarming, scheduling, or trending requirement |
| B-SS / B-SA | Smart Sensor and Smart Actuator: minimal devices that serve values (and accept writes, for B-SA) |
What Chipkin Provides
The CAS BACnet Stack implements the full BIBB set the B-BC profile requires, including the schedule execution engine and backup-and-restore. Talk to us about building or integrating a B-BC device on the stack.