BACnet/SC FAQs - Metasys - LIT-12013959 - 13.0

BACnet/SC Workflow Technical Bulletin

Brand
Metasys
Document type
Technical Bulletin
Document number
LIT-12013959
Version
13.0
Revision date
2023-09-29
Product status
Active
Language
English

What is BACnet/SC?

BACnet Secure Connect (BACnet/SC) is a new BACnet datalink ASHRAE 135-2020 Annex AB that provides secure message transport. BACnet/SC uses the standard IP application protocol, Secure WebSocket, which is an extension to HTTPS and runs over Transport Layer Security (TLS). BACnet/SC thereby provides a secure mechanism to authenticate and authorize a device to use the network. In addition, BACnet/SC eliminates the need for static IP addresses and network broadcast messaging. BACnet/SC works easily with firewall devices that are common in IT infrastructure and is fully compatible with existing BACnet IP systems and devices.

From Metasys Release 12.0, support for BACnet/SC uses mutually authenticated TLS-secured WebSocket connections. Mutual authentication means that two devices, the initiating peer and the accepting peer, that want to communicate by using BACnet/SC, must validate the following:
  • Validate that the peer's operational certificate is well formed.
  • Validate that the peer's operational certificate is active as of the current date and not expired.
  • Validate that the peer's operational certificate is not revoked, if such information is available.
  • Validate that the peer's operational certificate is directly signed by one of the locally configured CA certificates.

Do we support BACnet Addendum CD to Standard 135-2020?

Yes, Metasys Release 12.0 and later supports BACnet Addendum CD TLS v1.3 Cipher Suite Application Profile for BACnet/SC, which covers the minimum cipher suites that BACnet/SC supports for interoperability with other BACnet/SC devices. For more details about cipher suite support, refer to RFC8446 section 9.1 Mandatory-to-Implement Cipher Suites: https://datatracker.ietf.org/doc/html/rfc8446#section-9.1

Does BACnet/SC use Broadcast Management Devices (BBMDs)?

No. BACnet/SC eliminates BBMDs and their configuration.

Which version of TLS is supported?

BACnet/SC implementations support TLS version 1.3 for establishing communication connections between devices. Support of other versions of TLS or cipher suites beyond those required by TLS 1.3 is a local matter. For more information about additional supported TLS version and cipher suites, refer to:
  • FAC4911 Advanced Application Field Equipment Controller and VMA1930 VAV Modular Assembly Protocol Implementation Conformance Statement (LIT-12012572)
  • Metasys General Purpose Application Controllers Protocol Implementation Conformance Statement (LIT-12013102)
  • Metasys VAV Box Controllers Protocol Implementation Conformance Statement (LIT-12013104)

What are BACnet/SC certificates?

To establish a connection, each device needs to determine that it trusts the device it is trying to establish a connection with. For example, if Device A and Device B want to establish a connection between them, each device sends its operational certificate to the other device to authenticate.

An operational certificate is a term that BACnet uses for the certificate that a device uses for BACnet/SC communication. Operational certificates are also known as TLS certificates or identity certificates. The operational certificate is simply a file of information about the device, along with the device's public key and a digital signature by the Certificate Authority (CA) that issued the certificate. The operational certificate that contains the public key is paired with a private key securely held only on the device that generated it. A new public-private key pair is created by the device when it is requested to generate a Certificate Signing Request. You must request an operational certificate for all your devices on the BACnet/SC network.

BACnet/SC also requires that all devices have at least one signing certificate associated with it. Normally, a site uses one signing certificate, but BACnet/SC supports a second signing certificate for each device to facilitate switch-over to a different signing certificate for the site. A device uses the signing certificates to determine if it can trust the operational certificate presented to it by other devices that want to connect to it. All devices on the site have a copy of the same one or two signing certificates, so that they can mutually trust each other.

How do I manage my BACnet/SC certificates?

Use the BACnet/SC Management feature that is part of Metasys UI or Johnson Controls System Configuration Tool (JCT). In addition to this document, also refer to the BACnet/SC Management section of the Metasys UI Help (LIT-12011953) or Johnson Controls System Configuration Tool (JCT) Help (LIT-12012116) .

Metasys for Validated Environments (MVE) is available at Release 12.0.50, and not at Release 13.0. As the BACnet/SC Management feature is read-only for MVE on Metasys UI at Release 12.0.50, current MVE sites must use JCT for any BACnet/SC certificate management.

Figure 1. BACnet/SC Management feature in Metasys UI

What is the difference between BACnet/SC certificates and Metasys certificates?

In both cases, certificates are used as part of standard, secure communication between devices. However, there are differences between BACnet/SC certificates and Metasys certificates. The following table outlines these differences:
Table 1. Differences between BACnet/SC certificates and Metasys certificates
Area of comparison BACnet/SC certificate Metasys certificate
Communication BACnet/SC certificates are used to secure BACnet communication between supervisory devices and IP-based equipment controllers.
Metasys certificates are used to secure Metasys proprietary communication in the following areas:
  • Communication between the Site Director and site devices for traffic such as alarms, trend data, values, and similar.
  • Communication between the System Configuration Tool (SCT) and devices that SCT is interacting with.
  • Communication between the Site Management Portal (SMP) and the device connected to SMP.
  • Communication between the browser running the Metasys User Interface and the server.
Self-signed option BACnet/SC certificates do not support a self-signed option. Metasys certificates support a self-signed option.
Public CA

The signing CA is controlled by the site and can be a root CA or an intermediate CA.

This means a Public CA is not an option for BACnet/SC, a Private CA must be used.

While operational certificates for BACnet/SC use Elliptic-curve cryptography (ECC) encryption, the CA certificate can use ECC or Rivest–Shamir–Adleman (RSA) encryption.

Metasys certificates could optionally be signed by a public CA.
Certificate management BACnet/SC certificates are managed by the BACnet/SC Management feature in JCT or Metasys UI, but the public-private key pair is generated by the device the certificate will reside on. Metasys certificates are managed by SCT. The public-private key pair for a certificate is generated by SCT for each device it manages certificates for.
Certificate persistence The public-private key pair is only persisted on the device that was asked to generate it. The pair can only be deleted by employing the reset to factory defaults operation, as described in Performing a reset to factory defaults condition. Upgrades to the firmware or re-installation of server software do not delete them. The public-private key pair is part of the security archive for a device managed by JCT/SCT, and are downloaded to a device.
Encryption BACnet/SC certificates use ECC encryption. ECC encryption is considered more efficient. Metasys certificates use RSA encryption.

What is a public key?

A public key is the public portion of a cryptographic system's public-private asymmetric key pair. The public and private keys are mathematically linked to each other, so that a device (A) can give another device (B) its public key if it wants to communicate to it through secure communication. Device B can then encrypt the messages to send to Device A with A's public key. Only Device A can decrypt the message, which requires the corresponding private key that only Device A knows and keeps secret. Any device watching the communication cannot understand the message because it does not have Device A's secret private key to decrypt the messages sent from Device B to Device A.

What is a Certificate Authority (CA) and how does it sign the certificate?

A CA is an entity that issues the operational certificates to use for communication on a site. Before you can complete the process of importing certificates for the devices on a site, you must decide what will be the certificate authority used to generate the operational certificates.
Note: From Metasys Release 12.0, there are two options for the CA. You can request the customer's IT department to act as the CA, or from a third party.

When the CA creates the operational certificate for each device on the site, it places information in the operational certificate about the CA, or issuer. All BACnet/SC devices on a site need to have the certificate for the CA(s) they trust. BACnet/SC requires that all devices can trust up to two CA certificates.

When Device A receives a request from Device B to connect to it, A is presented with B's operational certificate. Device A can then examine Device B's operational certificate to determine which CA issued it. Device A checks if this is one of the CAs it knows about and trusts. The exchange happens on a bi-directional basis because BACnet/SC uses mutual authentication.

All devices on a site that communicate through BACnet/SC must have a certificate signed by one of the two CAs that are trusted by other devices on the site.

What is the difference between a certificate chain or trust chain and a signing certificate?

When a CA generates each operational certificate, it will likely include all the certificates that make up a certificate chain, starting with a trust anchor or root certificate. For example, a CA has a certificate chain that starts with MyRootCA and this is used to sign MyIntermediateA, which in turn is used to sign MyIntermediateB. MyIntermediateB is then used to sign all the BACnet/SC operational certificates. In this example, MyIntermediateB is considered the signing CA for each BACnet/SC operational certificate and is the CA that would be loaded onto every device. The rest of the certificates in the trust chain would be ignored.

Each operational certificate issued contains the Common Name of the issuer or signing CA. You can decode an operational certificate with a number of different tools available to see the issuer information. In this way, you can distinguish the issuing or signing certificate from possibly multiple CA certificates that make up a chain.

What needs to be in the import .zip file of operational certificates?

When you receive operational certificates from the IT department they may not be packaged in a way that enables you to directly use the Import functionality in the BACnet/SC Management feature. The basic requirements are that the certificates must be in .pem format and that the issuing or signing certificate that signed them must be present in the .zip file. You can assemble the operational certificates in the .zip file to ensure a successful import:
  • If each operational certificate is in a .pem file that includes the certificate trust chain (operational certificate must be first in the file followed by its issuer followed by each subsequent issuing certificate until the root), you can place these operational certificate files directly in the .zip file that you want to import. The import functionality automatically determines which is the signing CA and loads that into each device along with its operational certificate. The rest of the trust chain is ignored.
  • If the operational certificates are in a .pem file by themselves, you can place these operational certificate files directly in the .zip file, but you also need to add a .pem file that contains the signing CA to the .zip file. For example, a .zip file could contain five .pem files for five operational certificates and one .pem file for the signing CA. If the certificates that make up the rest of the trust chain are also included, they will not block anything, but are ignored.

What is a Certificate Signing Request (CSR)?

A certificate signing request is generated by a device as the first step to obtain a new operational certificate. The CSR contains information about the device and the public key from a newly generated public-private key pair. The information in the CSR becomes part of the operational certificate, along with information about the CA that created the operational certificate. After the operational certificate is issued and saved to the device, the CSR that was used is no longer needed.

How are certificates persisted?

To provide enhanced security, BACnet/SC certificates and their matching private key are only persisted on the device that generated the public-private key pair during the CSR step. Inclusion of the MAC address of a device in the Common Name in the certificate further binds it to a single physical device. To keep the private key secure there is no mechanism to ever retrieve it from the device. The certificate and the private key become part of the device and are not impacted by firmware upgrades or re-installation of server software. Changing the communication mode for the device also has no impact on the certificates that may be present. The certificate and private key can only be removed by the Reset to Factory Defaults operation, documented in Performing a reset to factory defaults condition.
Note: Because a certificate and its private key are bound to a physical device, replacing a device with a new one requires a new certificate to allow it to communicate through BACnet/SC.
The following table provides examples of situations in which BACnet/SC operational certificates are persisted or not persisted, respectively.
Table 2. Situations in which BACnet/SC operational certificates persist
Metasys device Situation Certificate persists
Equipment Controllers Switching between Ethernet IP Only and Secure Connect Only modes Yes
Downloading an application Yes
Downloading/Upgrading Boot/Main Code including application Yes
Downloading/Upgrading Boot/Main Code without application, that is reverting to Factory Default Application Yes
Issuing 999/979/989 sequence No, this operation erases the certificates
Replacing the controller No, the certificates are bound to the physical device
Engines Switching between Ethernet IP Only,Secure Connect Only, and Dual SC and IP modes Yes
Downloading an archive Yes
Downloading an archive including code or re-flash device in the same Metasys release or build Yes

Downgrading the engine to an earlier Metasys release and then upgrading the engine to Metasys Release 12.0 or later .

Yes
Resetting SNx engine using the Recovery button with or without partition swap No
Replacing the engine No, the certificates are bound to the physical device
Servers Switching between Ethernet IP Only, Secure Connect Only, and Dual SC and IP modes Yes
Downloading an archive Yes
Uninstalling the server without Remove databases selected Yes
Uninstalling the server with Remove databases selected Yes
Uninstalling of the server and cleaning C:\ProgramData\Johnson Controls\MetasysIII folder and SQL databases No
Upgrading OS Yes
Upgrading SQL Server Yes
Upgrading the server's Metasys software Yes
Replacing the server No
Replacing Ethernet card Yes

Do you need a license for BACnet/SC?

You need a license for BACnet/SC (M4-BACNETSC-0) if you use BACnet/SC on a Server site. You do not need a license for Engine-only sites. If two Metasys server class devices, such as ADS and NAE85, are used as a Primary Hub and Failover Hub respectively, two licenses are required.

What does the BACnet/SC topology look like?

BACnet/SC uses a hub-and-spoke topology. The central Hub Function performs message forwarding for all broadcast messages and for point to point messages for devices that do not support more efficient direct connections. All Metasys devices support direct connections. The following figure outlines the hub-and-spoke topology for BACnet/SC.

Figure 2. BACnet/SC network topology
Number Name Definition
1 Hub Function The Hub Function analyzes the traffic to determine whether it can be directed to another node or forwarded to all connected nodes. The Hub Function itself is also a node. The Hub Function is also responsible for forwarding broadcasts. Broadcasts must be sent from a node to the Hub Function, which then forwards to all other connected nodes. For more information, see also What is a Primary Hub? and What is a Failover Hub?
2 Node This can be a simple device, a more sophisticated device that routes to an existing BACnet system or the main workstation for the entire site.

Nodes initiate a WebSocket connection to a Primary Hub or Failover Hub. Nodes can optionally initiate or accept direct connections to other nodes.

The spokes are represented by the arrows with the full line. The optional direct connections are represented by the arrows with the dashed line.

What is a Primary Hub?

A Primary Hub device has both a node and a Hub Function. The node on the Primary Hub device connects to the Hub Function, as if it was a different device. The Primary Hub is expected to perform the Hub Function when reachable and always accepts WebSocket connections. A BACnet/SC site supports one Primary Hub only.

The following figure illustrates the normal scenario of the BACnet/SC network, where every node is connected to the Primary Hub.

Figure 3. Normal BACnet/SC network scenario

What is a Failover Hub?

A Failover Hub device has both a node and a Hub Function. The Failover Hub's node connects to the Primary Hub Function. If the Primary Hub Function is offline, then all nodes, including the Failover Hub's node, connect to the Failover Hub Function. The Failover Hub Function is always running on the site and always accepts WebSocket connections, even if the Failover Hub's node is connected to the Primary Hub Function. So, if some nodes are unable to connect to the Primary Hub Function, they connect to the Failover Hub Function, even if other nodes are able to connect to the Primary Hub Function. A BACnet/SC site supports one Failover Hub only. While it is optional to have a Failover Hub, it is best practice to configure a Failover Hub so as not to leave a site with a single point of failure.

The following figure illustrates the failover scenario of the BACnet/SC network, where the Primary Hub is offline and nodes get re-routed to the Failover Hub.

Figure 4. Failover BACnet/SC network scenario

Which Metasys devices support BACnet/SC?

From Metasys Release 12.0, the following devices support BACnet/SC:
  • Application and Data Server (ADS), ADS Lite-A, ADS Lite-E, and Extended Application and Data Server (ADX) as a hub only
  • Open Application Server (OAS), LonWorks® Control Server (LCS) 85, Network Automation Engine (NAE) 85, SNC, SNE, and NAE55xx-3x as supervisory devices
  • M4-CGE04060-0, M4-CGE09090-0, M4-CGE09090-0H, M4-CVE03050-0P, MS-FAC4911-0, and MS-VMA1930-0 as IP equipment controllers
    Note: You can upgrade existing VMA 1930 units in the field to support BACnet/SC, but this model is no longer manufactured.

What does the Number of Active WebSocket connections attribute of the SC Network Port object mean?

The Number of Active WebSocket connections attribute indicates the number of WebSocket connections that are currently active. A WebSocket connection is considered active, if the following conditions apply:
  • the connection is established
  • the connection has been created, but has not reached the established state, such as when the connection handshake is being negotiated
  • the connection is being disconnected, but not yet destroyed

The number of active connections includes every WebSocket endpoint that is currently serviced by the datalink. For devices that support the Hub Function, if the node is connected to the internal Hub Function, then the datalink services two endpoints for that connection, namely the endpoint on the node and the endpoint on the Hub Function. This internal hub connection is counted twice as a result.

Note: This does not mean that all connections are in the connected state of the BACnet/SC Connection State Machine. The Connect-Request/Accept messages may still need to be exchanged or Disconnect-Request/Ack messages are being exchanged.

Does communication traffic go through the hub or directly from device to device?

A device uses the hub initially to obtain information about another device that it wants to communicate with. While the BACnet/SC specification supports routing all communication between two devices through the hub, for best performance, all Metasys devices support the use of direct connections for peer communication and do not route peer communication through the hub. Broadcast messages always go through the Hub Function.

How do I choose a Primary Hub and Failover Hub for my Metasys system?

  1. Review your existing system and confirm your Site Director type, number of engines, and number of controllers.
  2. Confirm if you have any third-party BACnet/SC devices.
  3. Check the following table to ascertain if your Site Director can act as Primary or Failover Hub.
    1. Primary Hub: Confirm the number of IP connections you need to support and check it against the column called Maximum Primary or Failover Hub connections when loaded in the following table. If the number of engines plus the number of IP controllers in BACnet/SC plus the Failover Hub is equal to or less than the number under Maximum Primary or Failover Hub connections when loaded, you can use your Site Director as the Primary Hub.
      Note: If you have IP integrations such as Modbus, KNX, M-Bus, for example, then you have to add these to the IP connections count.
      Note: Include the Failover Hub in the IP connections count for the prospective Primary Hub.
    2. Failover Hub: If the number of engines plus the number of the IP controllers is equal to or less than the number in the column called Maximum Primary or Failover Hub connections when unloaded, is less than or equal to the stated number for an engine then use it as the Failover Hub. If not, consider using an NAE8500 as the Failover Hub.
      Note: For best performance in some cases, you can use the NAE8500 as Primary Hub and the ADS or ADX as the Failover Hub, because the ADS or ADX may already be very busy with its role as a Site Director. If you make the NAE8500 the Primary Hub, it handles all the duties of a Primary Hub, and the ADS or ADX occasionally has to act as Failover Hub in addition to its duties as a Site Director.
      Note: Do not include the Primary Hub in the IP connections count for the prospective Failover Hub, because it is offline when the Failover Hub is active.

Review the examples under the table for more information about how to apply these rules.

Table 3. Metasys devices, their role in the BACnet/SC topology, and maximum supported connections
Metasys device Primary or Failover Hub Maximum Primary or Failover Hub connections when loaded 1 Maximum Primary or Failover Hub connections when unloaded 2
ADX Yes 3 1,000 1,000
ADS, ADS Lite-A, or ADS Lite-E Yes3 750 750
NAE85 or LCS85 Yes3 150 750
OAS Yes3 150 200
All SNE models Yes. You can use the SNE1100 to save costs. 3 150 200
All SNC models Yes. 3 50 50
NAE55xx-3x Yes.3 150 200

M4-CGE04060-0,

M4-CGE09090-0,

M4-CGE09090-0H,

M4-CVE03050-0P,

MS-FAC4911-0, and

MS-VMA1930-0

No. These devices are only nodes, as they cannot act as Primary or Failover Hub. N/A N/A
Note: BACnet/SC Direct connections are not considered for simplicity and they are already accounted for with the reduced number of Maximum Primary or Failover Hub connections when the device is loaded. The engines must be at Release 12.0 or later with BACnet/SC enabled to act as BACnet/SC nodes. The equipment controllers must be at firmware version 10.0 or higher with BACnet/SC enabled to act as BACnet/SC nodes.
Example 1: This is a Metasys ADS Site Director system that can support BACnet/SC. The ADS in this example has four BACnet/SC Primary Hub connections, which is less than the 750 BACnet/SC Hub connection limit for the ADS. You can nominate the SNE 3 as the Failover Hub, because the three BACnet/SC Failover Hub connections is less than the allowed 150 BACnet/SC Hub connection limit for the SNE when it has any devices mapped under any of its integrations.
Figure 5. Example 1: Supported configuration with an ADS and MS/TP controllers
Note: All engines are running BACnet/SC. The ADS is acting as a Primary Hub, but it is not a native BACnet/SC device. In Example 1 there are no BACnet/SC direct connections from node to node.
Example 2: This is a Metasys ADS Site Director system that can support BACnet/SC. The ADS can be the BACnet/SC Primary Hub in this example and it has 140 BACnet/SC Primary Hub connections, which is less than the allowed 750 BACnet/SC Hub connection limit for the ADS. You can nominate the NAE 1 as the Failover Hub, because the 139 BACnet/SC Failover Hub connections is less than the allowed 150 BACnet/SC Hub connection limit when the NAE has any devices mapped under any of its integrations. The NAE 1 is chosen to be the Failover Hub over the other engines, because it has the lowest number of devices mapped under its integrations.
Figure 6. Example 2: Supported configuration with an ADS and IP controllers
Note: All engines are running BACnet/SC. The ADS is acting as a Primary Hub, but it is not a native BACnet/SC device. In Example 2, and for the purpose of demonstration, there are no BACnet/SC direct connections from node to node. Refer to Table 3 for controller model numbers.
Example 3: This is a Metasys ADS Site Director system that can support BACnet/SC, but the SNE2 cannot be the Failover Hub. The ADS can be nominated as the BACnet/SC Primary Hub in this example as it has 199 BACnet/SC Primary Hub connections, which is less than the allowed 750 BACnet/SC Hub connection limit for the ADS. However, even though SNE 2 has the lowest number of devices mapped under any of its integrations, and therefore, could be nominated as the Failover Hub, it cannot support this BACnet/SC site, because 198 Failover Hub connections is more than the allowed 150 BACnet/SC Hub connection limit when the SNE has any devices mapped under any of its integrations. The ADS has to be the Metasys site director, therefore, we recommend it be the Failover Hub, and the NAE8500 standalone server based engine be the Primary Hub.
Figure 7. Example 3: Unsupported configuration with an ADS
The solution is depicted in the following figure:
Figure 8. Possible solution to Example 3:

Can I add other protocols and services to sites that use BACnet/SC?

Yes, BACnet/SC supports the addition of standard messaging protocols and services, such as MQ Telemetry Transport (MQTT).

Why do I need BACnet/SC on an ADS/ADX?

You need BACnet/SC on an ADS/ADX if you want the ADS/ADX to perform the Hub Function. The ADS/ADX does not use BACnet/SC for other purposes.

Do I have to use BACnet/SC for the entire site?

No, you can selectively choose which devices communicate BACnet/SC, so you can integrate BACnet/SC devices gradually. However, BACnet/IP does require BBMDs on each subnet, so you have to make sure that the devices that communicate through BACnet/IP have the BBMDs configured to support the devices.
Note: Use BACnet/SC for the entire site to safeguard a site's security.

Can I use BACnet/SC and BACnet/IP on the same subnet?

Yes, but devices that communicate through BACnet/SC cannot communicate with devices that communicate through BACnet/IP only, regardless of the subnet they are on. Metasys supervisory devices support a dual communication mode where they can communicate both BACnet/IP and BACnet/SC at the same time.

Important: If you mix SC and IP on a site it must be done with care, especially at the supervisory level. From a BACnet point of view it can be viewed as two different sites. All the devices that talk BACnet/IP are one site and they can communicate to each other as well as broadcast to each other, if BBMDs are set up correctly. Likewise, all the BACnet/SC devices can communicate with each other and see each others broadcasts. Supervisory devices that are in dual communication mode participate in these two different sites, but they do not route between them. If you have an IP equipment controller in Secure Connect Only Mode it can talk to its supervisor if the supervisor is in Dual SC and IP Mode, or Secure Connect Only Mode. An IP equipment controller in Secure Connect Only Mode can only talk to peer equipment controllers that are in Secure Connect Only Mode. A supervisory device in Secure Connect Only Mode can only talk to other supervisory devices in Secure Connect Only Mode or Dual SC and IP Mode. This includes broadcasts.
Note: From a cybersecurity standpoint, a network with only BACnet/SC devices is the most secure. Mixing BACnet/IP and BACnet/SC devices on the same network can compromise the security of the network. A bad actor could send commands over BACnet/IP and have them execute on BACnet/SC controllers.

Can BACnet/SC devices be distributed across subnets/VLANs?

Yes, as long as the network is configured to route messages between the subnets/VLANs, the nodes and BACnet/SC hubs can reside on different subnets/VLANs. We place the BACnet/SC hubs, along with the engines, in the IT subnet allocated to the BAS (hereafter called BAS subnet). The IT network provides the routing, so that any BACnet/SC nodes in the IT network can reach the BACnet/SC hubs in the BAS subnet. Switches provide the routing, so that the BACnet/SC nodes in the BAS private space, that is the equipment controllers, can reach the BACnet/SC hubs and the engines in the BAS subnet.

Can I connect BACnet/SC networks together?

Yes, you can connect BACnet/SC networks together with a third-party BACnet/SC to BACnet/SC router. There is no limit to the number of routers you can use to connect BACnet/SC networks together.

Where does the field technician connect to the network to install the certificates on the BACnet/SC devices?

To use the BACnet/SC Management feature, you need to connect to the Site Director to install certificates for all supported Metasys devices on a site, or connect to an engine to install certificates on the engine and its integrated equipment controllers.

Can I use Domain Name System (DNS) to specify the Primary and Failover Hub Uniform Resource Identifier (URI)?

Yes, but you cannot use a URI with the full DNS name of the devices as the Primary Hub or Failover Hub URI. If you use the full DNS name, the device intended to be the hub fails the string comparison and becomes a node instead of a hub. Ensure that the DNS Server is configured to allow the short host name to be used.

Always ensure that the DNS name can be resolved by all devices that use BACnet/SC, particularly the IP equipment controllers, as they can be on their own subnet.

Who is responsible for the long-term storage and safe keeping of certificates?

Each Metasys BACnet/SC device securely stores its own operational certificate and the matching private key. The certificate is kept in a secure location on each device and is maintained even if the device has its firmware or archive changed. For security purposes, there is no mechanism to upload the private key for a device.

What is the level of support that we offer to third-party devices on a Metasys BACnet/SC configuration?

The level of support offered is the same as we offer to third-party devices on a Metasys BACnet/IP configuration. Additionally, third-party devices need to use their own tool to put a certificate onto them as there is no standardized way to do this in BACnet until devices support Addendum CC of the ASHRAE 135-2020 BACnet protocol standard.

Can I use Metasys BACnet/SC devices on a third-party BACnet/SC configuration?

Yes. Use the BACnet/SC Management feature in Metasys UI or JCT to configure a supervisory device for use in a third-party system. Metasys equipment controllers also work but to set them up, they have to be connected to a Metasys supervisory device such as an M4-SNC , have the certificates loaded through Metasys UI or JCT, and then connected to the third-party site.

Does an ADS or ADX that performs the Hub Function continue to perform broadcast management for BACnet/IP devices?

Yes, an ADS or ADX that performs the Hub Function continues to perform broadcast management for BACnet/IP devices.

How can I determine the expiration status of my certificates?

Both the operational certificates and the longer-lived signing certificates can expire. You can use the information displayed on the Devices tab of the BACnet/SC Management feature to determine the status of your certificates.

For engines and IP equipment controllers you can also open the Device object or Mapper Device object and go to the Detail widget to see information about the operational certificate status.

Will I receive a reminder before my certificates expire?

Yes, you will receive certificate expiration reminders that start a configurable number of days before a certificate expires for a device, and then daily until you renew the certificate. The reminder takes the form of an alarm in System Activity, Alarm Manager, and Alarm Monitor. Use the Certificate Renewal Period property of the Detail widget of the Site Object to configure the launch of the reminders.
Note: A change to the setting is automatically distributed to every site device.

Will BACnet/SC work on the Media Redundancy Protocol (MRP) Ring?

IP controllers in BACnet/SC mode will work in an MRP Ring although the IP Network Wizard tool used to configure the Ring Manager switches (that is the Cisco IE 2000 switches) for BACnet/IP does not yet support BACnet/SC. Therefore, the IP Network Wizard tool cannot currently be used to configure the Ring Manager switches for BACnet/SC.

How do I deal with an existing MRP Ring if I want to use BACnet/SC?

Until BACnet/SC is supported on the IP Network Wizard tool, manual changes are required to the Ring Manager switches' Access Control Lists (ACLs) configuration to allow the BACnet/SC-related protocols, as well as to account for the BACnet/SC Hubs (Primary and Failover). Specific Cisco switch configuration knowledge is required to do this, so it is recommended to continue to use BACnet/IP until the BACnet/SC support on the IP Network Wizard tool is officially released.

1 Loaded means that the Metasys device has at least one device mapped under any of the Metasys device’s integrations, including IP, KNX, LON, M-Bus, Modbus, MQTT, MSTP, and OPC UA.
2 Unloaded means that the Metasys device has no devices mapped under any of the Metasys device’s integrations, including IP, KNX, LON, M-Bus, Modbus, MQTT, MSTP, and OPCUA.
3 This device can act as a BACnet/SC node as well as a BACnet/SC Primary or Failover Hub.