TwinCAT 3 from Beckhoff integrates all important subsystems such as Bachnet and also supports BACnet Rev. 14 with TwinCAT 3 BACnet (TF8020) (Source: Beckhoff)
BACnet/SC nodes support a fail-over mechanism that ensures a functioning system if the hub fails or is taken offline for maintenance or upgrade. (Source: ASHRAE; Graphic: b&a)
Use of certificates
The TLS1.3 standard uses X.509 certificates, which are signed by a central certificate authority (CA) to allow devices to trust each other. When a device presents the certificate to the hub, it checks details such as its validity, expiration date, and CA authentication.
The CA does not have to be provided externally; it can be operated locally as part of the IT infrastructure using software like OpenSSL, but proper access control is essential to prevent security breaches.
Organizational challenges for building automation
All of these technical requirements give rise to a whole host of new organizational tasks and challenges in practice. Cyber certificates are only secure if they are regularly replaced; those with very long (e.g., several years’) or even unlimited validity are worthless. If the certificate for a device expires and is not renewed, it is no longer possible to communicate with that device until the certificate is updated. This raises the question during projects of who is responsible for these tasks and for performing regular updates: the system integrator during annual maintenance, the facility manager, or the IT department?
To automate this process, the BACnet standard defines a procedure in which a device generates a certificate signing request (CSR) as a file. This file is then transferred to the CA, where it is signed and returned to the device as a signed certificate. With this procedure in place, certificates can be replaced with minimal effort and therefore updated at regular intervals.