It is prudent to limit tasks and responsibilities of central components as this can easily result in single points of failure. The principle applies as well to BACnet/SC hubs. The total number of nodes for a hub is limited in two ways:
- By performance
- By IT best practices that limit the number of devices central devices
As mentioned above, it is always a good practice to locate networks in the same area (building, floor, plant) where possible:
- Design BACnet networks to retain most of the traffic on the individual networks while limiting traffic routed across networks. In other words, adhere to the scopes in the building.
The BACnet/SC topology described to this point is flat with just nodes and a dedicated single hub. Several single-hubs can be set up as needed with each hub forming its own BACnet/SC network that BACnet routing can interconnect much the same as BACnet/IP and BACnet/MSTP networks in the past (on a common BACnet internetwork).
Currently, the system supports the creation of islands of BACnet/SC networks with their own hubs, using BACnet routing to interconnect the BACnet/SC networks.
This is also one of the main reasons that BACnet/SC hubs nearly always host BACnet router functionality (to allow routing across BACnet networks). The approach retains a flat structure of multiple single-hub topologies, interconnected by a BACnet/IP network (or the reverse: Multiple BACnet/IP networks interconnected by a BACnet/SC network). For special conditions, this does in fact constitute an improvement to a project's overall cybersecurity situation.
Outlook: Hierarchical hub-of-hub topologies
Single-hub network topologies are still, however, restricted in their capacity by the number of BACnet/SC nodes. On large projects this calls for multi-hub architectures for BACnet/SC networks that are similar to BACnet/IP network hierarchies.
See BACnet/IP networks [➙ 24].
The primary approach is to build a tree-like hierarchy or hub-of-hub structure by turning subordinate hubs into nodes of another subordinate hub. Simply connecting nodes however in a haphazard way creates the same traffic problems encountered earlier with (symmetric) BBMDs, i.e. all the traffic is combined into a single network that accumulates project traffic up the hierarchy to the top or root hub: The hub at the very top of the hub-of-hub topology must handle all the traffic on the project, but also propagate the traffic back to the rest of the site.
The first improvement was already outlined above: Organize BACnet networks to the building (building, floor, plant). This simple step lowers the amount of data transmitted up and down the network.
A better approach is to:
- Organize the hierarchy according to the typical building structure: Floors-plants-building-system-site.
- Route only traffic from the hierarchy to that hub level where it is needed.
- Reuse something similar to the asymmetrical BBMD principle to determine whether the data need only be sent up the hub hierarchy to a BMS (as the typical requester for all information over the entire BACnet system), or down the hierarchy to room controllers.
In more complex multi-hub topologies, the BACnet/SC hubs are typically located where the BACnet Broadcast Management Devices (BBMD) are currently depicted in BACnet/IP topologies. BACnet/SC and BACnet/IP topologies simplify phased migration of an installed BACnet/IP base to BACnet/SC.
The BACnet/SC standard does not define how to design and balance traffic loads on large systems as this document does, for example, in the section on asymmetric BBMDs in BACnet/IP.