This piece was originally published in the July/August 2019 issue of electroindustry.
Scott Ziegenfus, Systems Architect, Hubbell Lighting
Even though it’s not published yet, it’s possible you’ve heard something about BACnet Secure Connect (BACnet/SC), which has sparked a significant amount of buzz in the building systems industry. The name itself triggers curiosity. Here are some questions you may be asking:
- How secure is it?
- How different is it from the BACnet we use today?
- Does it allow BACnet to work in the world of IoT?
- How IT “friendly” is it?
- What is the difference between the BACnet/IP and BACnet/SC?
Let’s cover all of the above.
The original name, “Internet Transport Bindings,” was the brainchild of Bernhard Isler, a System Architect for Siemens and former Chair of the SSPC 135 BACnet Committee. The name was edited to convey the magnitude of this addition to the Standard, and the committee settled on BACnet Secure Connect. Described simply in a single sentence, BACnet Secure Connect implements the entire BACnet stack in the application space, as noted in Figure 1.
Why is moving to the application space vital? From the beginning, BACnet has always been a network communications protocol with an architecture based on the IT model. However, BACnet is a protocol adapted to the unique communication needs of relatively lightweight controllers and other resource- limited devices. While using the basis of standard IT protocols it will, at times, deviate on how they are implemented. This pushes IT departments to adapt to how BACnet is implemented on its IT infrastructure, rather than fitting into the current IT framework. Moving to the application space allows for easier IT adoption. Benefits include:
- Additional support of DNS and DHCP
- Elimination of IT structures unique to BACnet like BACnet Broadcast Management Devices (BBMDs)
- Takes away the requirement for User Datagram Protocol (UDP) broadcast messages
- No special requirements for firewalls and Network Address Translation (NAT)
- Moves to the use of Transmission Control Protocol (TCP) instead of requiring UDP
These are all things that make it a “business-as-usual” proposition with IT.
BACnet/SC is essentially another datalink in the Standard just like Master/Slave Token Passing (MSTP) or Ethernet supporting the BACnet Network Layer (NPDU) and BACnet Application Layer (APDU).
However, it is meant to live entirely in the application space. This allows BACnet/SC to live on top of the standard information flow layers of the TCP/IP model common to network IT infrastructures, as noted in Figure 1.
The BACnet/SC datalink connects from the application space to the IT world using the TCP- based WebSocket protocol (RFC 6255) developed for browser-based applications as extensions to HTTP. The WebSocket protocol allows the use of port 80 for regular WebSocket connection or port 443 for secure WebSocket connections over Transport Layer Security (TLS). However, BACnet/SC mandates that only the use of secure WebSocket connection over TLS is allowed, as noted in Figure 1.
Because BACnet/SC is a datalink, conversion from SC to any other datalink can be accomplished by a BACnet router. As in all BACnet routers, the BACnet message or command within the APDU remains unchanged as the message wrapper gets stripped and reapplied for the new datalink. This will allow an existing network of BACnet devices using a datalink of IP or MSTP to be converted to BACnet SC for network adaptions, as noted in Figure 2.
The logical topology of BACnet/SC communication is hub and spoke. BACnet devices will be considered as nodes. Nodes are any BACnet device, from an Advanced Workstation (AWS) to a Smart Actuator (SA). A hub will monitor and assess the communications and provide the switch function from a device node and to its destination node. If required it will also send it to all of its connected nodes.
For redundancy, a second hub may be added to the network as a failover hub. All BACnet/SC nodes are required to support connecting to the main or primary hub. In the event of a failure it will connect to a failover hub. Nodes also can talk directly to other nodes, as noted in Figure 3.
This additional datalink allows for multiple configurations when the logical topology of hub and spoke combined with BACnet/SC in the application space. Configurations can be across a campus or the world, in the cloud or on a corporate intranet, as noted in Figure 4.
To recap, let’s answer the original questions noted at the beginning of this article.
Is it different than the BACnet we use today?
The BACnet message is still the same, but the datalink is different. Today, plenty of off-the-shelf BACnet IP to MSTP routers are available to route between a BACnet/IP network and BACnet MSTP network. While the medium changes, the BACnet message stays the same. There will be no difference routing between a BACnet/SC network and a BACnet/IP or MSTP network.
How “IT friendly” is it?
It allows IT to use the conventional methods, procedures, and protocols Standard in the IT world, making it extremely friendly. BACnet/SC eliminates aspects of BACnet/IP that are sometimes problematic because it deviates from conventional IT policies and practices such as BBMDs and UDP broadcasting. BACnet is not dictating how the physical, datalink, network, or transport layers of the TCP/IP model are to be used or tweaked for BACnet. The methodology for information flow is left to the local IT policies and procedures.
How secure is BACnet/SC?
BACnet Secure Connect does not use Clause 24 in the BACnet Standard (the security clause). Although Clause 24 is a sophisticated network security solution of authentication, authorization, and encryption, it uses a vastly different approach to security that doesn’t follow the current thinking and Standards widely used by the IT world. Instead, BACnet/SC requires the latest version of Transport Layer Security (TLS). Where Clause 24 was optional and not widely used for BACnet/SC, TLS is not an option and will always be implemented—thus the name BACnet Secure Connect.
What is the difference between BACnet/IP and BACnet/SC?
BACnet/IP allowed BACnet to be adopted on an IP- based network. It also mandated installation criteria such as the need for message broadcasts and the use of UDP for the transport layer. Additionally, security methodology used would be from the BACnet own Standard under Clause 24, or expensive Virtual Private Network (VPN) solutions. This adoption required IT departments to adapt their network to BACnet requirements instead of having BACnet adapt to the IT department protocols and procedures.
BACnet/SC moves the BACnet stack into the application space and allows BACnet to effectively fit any IT department’s procedures using common IT practices. The only requirement is to use “secure” WebSockets employing the common TLS security Standard.
Does it allow BACnet to work in the world of IoT?
Moving to the entire BACnet stack in the application space and using a hub and spoke topology for the logic flow allows the hub, along with any device nodes, to live on premises, at the Edge, or in the cloud, or any combination controlling BACnet data flow. The flow of data is the basis for IoT.
The addendum for BACnet/SC is Addendum bj and is expected to be out for third public review by the time of this publication. All SSPC 135 BACnet Committee addendums out for public review can be found on the American Society of Heating, Refrigerating and Air- Conditioning Engineers (ASHRAE) website at https:// www.ashrae.org/technical-resources/standards-and- guidelines/public-review-drafts. ei