What B-SCHUB 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-SCHUB (BACnet Secure Connect Hub) is defined in Annex L of ANSI/ASHRAE 135-2024 (clause L.7.6) as a device that performs the BACnet Secure Connect hub function, accepting the secured WebSocket connections that BACnet SC nodes open to it.
It is a Miscellaneous-family profile, which means a device can claim it alongside a profile from another family: a building controller that is also the site’s BACnet SC hub claims both B-BC and B-SCHUB. The checklist items are BACnet Interoperability Building Blocks (BIBBs); a device documents its claim in its PICS (Protocol Implementation Conformance Statement).
Where It’s Used
B-SCHUB is the profile for whatever device runs the hub at the center of a BACnet SC network.
- The site hub. The device every BACnet SC node connects to, fanning messages out across the secured network.
- A hub built into a controller or gateway. A supervisory device that carries the hub function in addition to its control or translation role.
- A failover hub. A second hub that nodes name in
SC_Failover_Hub_URIand fall back to on their own. It is an ordinary B-SCHUB device; the two hubs do not coordinate. (Automating that fallback on the node side is a CAS BACnet Stack 6.x item; see what ships today.)
Required Services
The set below reflects the BIBBs commonly required of a hub device. Verify it against clause L.7.6 of ANSI/ASHRAE 135-2024 before you write your PICS.
The table below is the application-service set required by the B-SCHUB BIBBs. Executes means the device receives and acts on it (responding, for confirmed services); Initiates means it sends the request or notification. BIBB codes encode the same split: a -A BIBB initiates, a -B BIBB executes. A - means the profile does not require that direction; a device may still support it.
| Capability area | Service | Required by BIBB | Initiates | Executes |
|---|---|---|---|---|
| Data sharing | ReadProperty | DS-RP-B | - | Yes |
| Device and network management | Who-Is | DM-DDB-B | - | Yes |
| Device and network management | I-Am | DM-DDB-B | 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 |
The defining requirement is not an application service. B-SCHUB additionally requires the Secure Connect hub function, NM-SCH-B, which carries the BACnet SC datalink messages (connect, advertise, heartbeat, disconnect) rather than an application-layer service. That BIBB is what makes the device a hub; the services above are the ordinary device-management surface every BACnet device exposes.
Related Profiles
| Profile | How it relates to B-SCHUB |
|---|---|
| B-BBMD | Broadcast Management Device: the BACnet/IP broadcast-transport role that BACnet SC’s hub replaces |
| B-BC | Building Controller: a common base profile to stack the hub function onto |
| B-RTR | Router: another infrastructure profile a hub device commonly carries as well |
What Chipkin Provides
B-SCHUB is supported in the CAS BACnet Stack today. The shipping stack implements the BACnet SC hub function (NM-SCH-B) and the device-management services listed above. A PICS is your own declaration, so a device on 5.x can claim B-SCHUB now, alongside whatever control or gateway profile it already carries.
What is not yet in place is the evidence behind that claim: per-function BTL conformance is unverified, and a BTL Listing is granted to a finished product rather than to a stack. The CAS BACnet Stack 6.x release exercises the profile against the BACnet Testing Laboratory’s published test plans. That is a difference in proof, not in function. Talk to us about building or integrating a B-SCHUB device on the stack.