BACnet devices must find one another to communicate end-to-end.

UDP broadcasts are implemented in BACnet/IP for the corresponding broadcasts but UDP broadcasts scale poorly and can result in broadcast storms on larger installations. In addition, UDP broadcasts end by design at the boundary of an IP subnet, as IP routers do not route broadcasts between IP subnets. This technical limitation is the reason why the BACnet standard introduced BACnet Broadcast Management Devices (BBMD) in the first place. BBMDs send UDP traffic across IP subnets, but this is counter to what IT administrators want: It increases the risk of poor scalability and broadcast storms.

BACnet/SC avoids both problems by using a central server-like approach to replace peer-to-peer broadcast discovery under BACnet/IP:

  • Each BACnet/SC network has a dedicated central hub device that the other BACnet/SC devices know and use to communicate with another device.
  • All other BACnet/SC devices are nodes (spoke) and are assigned to the hub during engineering.
  • WebSockets implement node-to-hub communication and rely on TCP as the underlying protocol.

The result is that all end-to-end communications between any pair of BACnet/SC nodes on a BACnet/SC network are routed through the central hub and BACnet broadcast commands are translated to simple TCP-based commands from the node to its hub rather than potentially flooding the network with UDP traffic.

BACnet/SC does allow two nodes to negotiate to dispatch node-to-node, but the nodes must still maintain their hub-and-spoke connection for control purposes. Note also that IT administrators are likely to consider this direct connect as not IT-friendly. The Desigo system currently does not support direct connections.

Logical structure of a BACnet/SC network

Nodes use a hub as a relay to communicate end-to-end.

Key

BACnet/SC hub

BACnet/SC node

Physical structures of a BACnet/SC network

The physical structure of a BACnet/SC network is completely independent of the logical structure.

For example, no changes in cabling are required to migrate BACnet/IP to BACnet/SC. Note: A message must travel from the source node to the hub and back to the destination hub and a daisy chain might—in a worst-case scenario—traverse the chain twice (if both nodes sit at one end of the chain with the hub residing at the other). This is not a problem as long as the system remains below the approved system limits; but given the choice, placing the hub into the middle of a daisy chain is an easy way to mitigate the issue.

Hubs are critical components in a BACnet/SC system and as such we strongly recommend against using a daisy chain topology. Where this is not feasible, design a ring structure (for redundancy in the event of a link failure) to protect the daisy chain.

Star/bus

Key

BACnet/SC hub

BACnet/SC node

Daisy chain

Key

BACnet/SC hub

BACnet/SC node

1. Managing all encrypted traffic from the nodes requires considerable hub resources. Comply with all limits on the maximum number of nodes per hub. See the corresponding data sheets.

2. While technically possible, avoid hubs in daisy chains. Where unavoidable, place the hub directly as the first element on the Ethernet switch. Reason: Daisy chains have a higher risk of network failure which counteracts the requirement that hubs be high-availability core elements.