BACnet/SC Hub

The BACnet/SC logical network architecture is centered around the hub which acts as a central component to which all other BACnet/SC end point devices (nodes) connect. Every BACnet/SC network must have at least one active hub – the primary hub, which must always be reachable. All devices on the BACnet/SC network other than the active hub are nodes. Hubs are best implemented on embedded devices, such as system controllers, which are designed to be resilient to failure and are powerful enough to support many simultaneous node connections as well as BACnet routing between different BACnet data links, while also performing their task as a building automation controller. Any device supporting the hub function falls under the BACnet Secure Connect Hub (B-SCHUB) standardized device profile indicated in the PICS of the device in addition to any other standardized device profiles also supported by the device, and support of the Secure Connect, (Annex YY) link layer option and the Network Management-Secure Connect Hub-B (NM-SCH-B) BIBB.

While the B-SCHUB device profile clearly indicates BACnet/SC hub devices when searching BTL listings, there is no device profile which clearly indicates BACnet/SC node devices. The only way to identify node devices from their device profile is to check if the BACnet/SC datalink layer is supported at the Annex YY.

There can only be one active hub on a BACnet/SC network (defined by network number and port number) at a time. It is strongly recommended that BACnet/SC networks are implemented with a redundant hub to avoid downtime. The failover hub can be another system controller on the network with BACnet/SC hub functionality. Any device with hub functionality is also inherently a node. While the primary hub is active, the failover hub acts as a node until a situation occurs where the primary hub cannot be reached. Once that happens, nodes are configured to look for the failover hub and connect to it. Nodes switch over to the failover hub and communication continues after a minimal interruption.

Since any device with hub functionality is also inherently a node, once the two recommended hubs (primary and failover) are in place on the network, the same device with hub capability can be used as a controller acting as a BACnet/SC node when needed for reasons other than its hub functionality.

The BACnet/SC logical network architecture is an improvement over BACnet/IP, which uses UDP broadcasts and BACnet Broadcast Management Devices (BBMDs) if the BACnet system comprises more than just one IP-subnet. Historically, BBMDs have been a challenge to configure in large systems due to the potential deep impact of the underlying IP network behavior. BACnet/SC networks are completely independent of the underlying IP network structure. In an extreme implementation, all devices (nodes and hubs) could be scattered arbitrarily into different IP networks around the project. As long as the nodes can reach their hub, the BACnet/SC communication will work. The primary and failover hubs must be known to their nodes. This either requires a static IP address for the hub or a Fully Qualified Domain Name (FQDN). An FQDN requires a working Domain Name System (DNS) in the engineering and commissioning phase to be functional already. If a certificate is to be generated for this FQDN, it must be created by an official and trusted Certificate Authority.

BACnet Broadcast Management Devices (BBMDs) are not needed with BACnet/SC. BACnet/IP networks only need BBMDs if the network is comprised of mixed BACnet segments. Once BACnet/IP devices reach a BACnet/IP to BACnet/SC router and are routed to BACnet/SC at that connection point, no more BBMDs are needed on the routed BACnet/SC network – the hub can propagate messages to nodes across subnets. The connections in BACnet/SC are outbound (similar to a local web browser connection to a server on the Internet). Nodes initiate the connections to the hub. This is intentional and makes BACnet/SC very IT friendly, especially in IP micro-segmentation use cases where it is applied as a network security technique enabling network architects to logically divide the network into distinct security segments down to the individual workload level, and then define security controls and deliver services for each unique segment.