BUILDING MANAGEMENT SYSTEM WITH EXPIRED OPERATIONAL CERTIFICATE RECOVERY

Methods and systems for reconnecting a device with an expired device operational certificate in a building management system (BMS) are disclosed. One method includes identifying that a device operational certificate of a first device has expired, sending an instruction to a second device to accept the expired device operational certificate as valid, receipt of the instruction causing the second device to relax an expiration date and accept the expired device operational certificate as valid, and delivering a replacement device operational certificate to the first device to replace the expired device operational certificate.

BACKGROUND

A building management system (BMS) is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include a heating, ventilation, and air conditioning (HVAC) system, a security system, a lighting system, a fire alerting system, and any other system that is capable of managing building functions or devices, or any combination thereof. A BMS may include a variety of field devices (e.g., HVAC devices, controllers, chillers, fans, sensors, etc.) configured to facilitate monitoring and controlling building spaces. Field devices can be configured to communicate with other devices via a network, such as a Building Automation and Control network (BACnet) or a Local Area Network and from potential external attacks.

A BMS may employ a secure protocol such as a standard TLS protocol to protect the field devices and the system from cyberattacks. Devices in the BMS include a stored digital operational certificate which permits communication between devices in the BMS. The devices mutually authenticate each other's certificate to determine whether to trust the other and allow communication. In some circumstances, the certificate may expire, thus preventing a device from communicating with other devices in the BMS in the manner required to carry out its functions. The expiration of an operational certificate generally requires a technician to go to the device and physically perform a factory reset in order for the device to receive a renewed operational certificate. Field devices may be in remote areas and difficult to access. As such, it would be advantageous for a device in a BMS to communicate with the other devices for a period of time using an expired certificate and to replace the expired operational certificate without the need for a physical factory reset.

SUMMARY

One implementation of the present disclosure relates to a method of reconnecting a device with an expired device operational certificate in a building management system (BMS). The method includes identifying that a device operational certificate of a first device has expired, sending an instruction to a second device to accept the expired device operational certificate as valid, receipt of the instruction causing the second device to relax an expiration date and accept the expired device operational certificate as valid, and delivering a replacement device operational certificate to the first device to replace the expired device operational certificate.

In some embodiments, the method further includes receiving an indication from the second device that each of one or more other attributes of the device operational certificate indicate that the device operational certificate would otherwise be valid if not for being expired, wherein accepting the expired operational certificate as valid is performed in response to determining that the certificate would have otherwise been valid if not for being expired.

In some embodiments, the one or more other attributes comprise the device operational certificate being well formed, the device operational certificate not having been revoked, or the device operational certificate having been signed by a locally configured certificate authority (CA).

In some embodiments, identifying that the device operational certificate of the first device has expired comprises receiving an indication from the first device or second device that the device operational certificate has expired.

In some embodiments, relaxing the expiration date to accept the expired device operational certificate as valid comprises one of removing an expiration date to accept an expired operational certificate or adjusting the expiration date to accept an operational certificate that is expired by less than a predetermined amount of time.

In some embodiments, delivering the replacement device operational certificate to the first device to replace the expired device operational certificate comprises retrieving the replacement device operational certificate from a locally configured CA.

In some embodiments, the method further includes resetting a connection between the first device and the second device, and validating the replacement device operational certificate.

In some embodiments, sending an instruction to the second device comprises sending an allowable expired list of device operational certificate fingerprints that are acceptable even if expired.

Another implementation of the present disclosure relates to BMS that includes a first device comprising a device operational certificate and a second device comprising one or more processors and one or more computer-readable storage media having instructions stored thereon. When executed by the one or more processors, the instructions cause the one or more processors to implement operations comprising identifying that the device operational certificate of the first device has expired, receiving an instruction to accept the expired device operational certificate as valid, and relaxing an expiration date requirement to accept the expired device operational certificate as valid.

In some embodiments the operations further include confirming that each of one or more other attributes of the device operational certificate indicate that the device operational certificate is valid.

In some embodiments, the one or more other attributes comprise the device operational certificate being well formed, the device operational certificate not having been revoked, or the device operational certificate having been signed by a locally configured certificate authority (CA).

In some embodiments, identifying that the device operational certificate of the first device has expired comprises receiving, from the first device, a fingerprint of the device operational certificate.

In some embodiments, relaxing the expiration date requirement to accept the expired device operational certificate as valid comprises one of removing an expiration date to accept an expired operational certificate or adjusting the expiration date to accept an operational certificate that is expired by less than a predetermined amount of time.

In some embodiments, the BMS further comprises a user interface device comprising a user interface configured to display a plurality of icons, each corresponding to one of one or more devices and configured to indicate a connection status of each of the one or more devices.

In some embodiments, the user interface device is configured to send an instruction to one or more devices in the BMS to accept the expired device operational certificate as valid.

In some embodiments, receiving an instruction to accept the expired device operational certificate as valid comprises receiving an allowable expired list of device operational certificate fingerprints that are acceptable even if expired.

Another implementation of the present disclosure relates to a method of replacing an expired device operational certificate. The method includes identifying that a device operational certificate of a first device has expired, receiving an instruction from a user interface device to accept the device operational certificate that has expired as valid, relaxing an expiration date requirement and accepting the expired device operational certificate as valid, receiving a replacement device operational certificate from the user interface device, and delivering the replacement device operational certificate to the first device.

In some embodiments, receiving an instruction from a user interface device to accept the device operational certificate that has expired as valid comprises receiving an allowable expired list of device operational certificate fingerprints that are acceptable even if expired.

In some embodiments, the method further includes confirming that the replacement device operational certificate is valid.

In some embodiments, the method further includes communicatively connecting to the first device in response to confirming that the replacement device operational certificate is valid.

DETAILED DESCRIPTION

Overview

Referring generally to the FIGURES, systems and methods for permitting communication in a BMS with a device with an expired operational certificate and replacing the expired security certificate are shown, according to various embodiments. Various devices may connect to and communicate with each other in a BMS. The devices may be, for example, field devices, user interface devices, sensors, actuators, and supervisory devices, or any other component configured to communicate with the BMS. Field devices typically control a specific equipment or a larger system, such as a chilled water system, and may communicate directly with other field devices to coordinate operation. A supervisory device may control higher level building strategies, such as optimization, startup scheduling for a whole floor or building, and high-level monitoring. Field devices may communicate with one or more supervisory devices. Sensors and actuators that are capable of IP communication may also communicate with field devices and supervisory devices.

In order to enable communication between two devices, each device must authenticate the operational certificate of the other. If both certificates are valid, communication between the devices is permitted. If one of the operational certificates has expired, communication will generally not be permitted between the devices. However, there may be circumstances in which it is desired or necessary for a device with an expired operational certificate to continue to communicate with the other devices in the BMS until the certificate can be replaced.

In the disclosed embodiments, an instruction may be sent to the devices in the BMS to accept an expired certificate from one or more specified devices. This allows the specified devices to continue to communicate with the other devices in order to maintain the proper operation of the BMS. A user may connect to the BMS using a user interface device and instruct the other devices to accept specified expired operational certificates as valid. This may function similar to a TLS revocation list, except that, instead of pushing a list of revoked certificates to the devices in the BMS, a temporarily allowed expiration list is pushed to the devices. An instruction may be sent to the devices to ignore the expiration date for operational certificates on the list. When a new, unexpired operational certificate is available for a device, the user may input commands in to the user interface device to replace the expired certificate with a new one. Thus, the operational certificate of a device can be replaced with a valid certificate without the need for a technician to physically perform a factory reset on the device. Once a valid operational certificate has been delivered to the device, connections between the devices may be reset. The device will then possess a valid operational certificate and may communicate with the other devices in the BMS as usual.

Building Management System

Referring now toFIGS.1-4, several building management systems (BMS) and HVAC systems in which the systems and methods of the present disclosure can be implemented are shown, according to some embodiments. In brief overview,FIG.1shows a building10equipped with a HVAC system100.FIG.2is a block diagram of a waterside system200which can be used to serve building10.FIG.3is a block diagram of an airside system300which can be used to serve building10.FIG.4is a block diagram of a BMS which can be used to monitor and control building10.

Referring particularly toFIG.1, a perspective view of a building10is shown. Building10is served by a BMS. A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area interconnected by a Local Area Network (LAN). A BMS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof.

In some embodiments, HVAC system100uses free cooling to cool the working fluid. For example, HVAC system100can include one or more cooling towers or heat exchangers which transfer heat from the working fluid to outside air. Free cooling can be used as an alternative or supplement to mechanical cooling via chiller102when the temperature of the outside air is below a threshold temperature. HVAC system100can switch between free cooling and mechanical cooling based on the current temperature of the outside air and/or the predicted future temperature of the outside air.

Although subplants202-212are shown and described as heating and cooling water for circulation to a building, it is understood that any other type of working fluid (e.g., glycol, CO2, etc.) can be used in place of or in addition to water to serve thermal energy loads. In other embodiments, subplants202-212may provide heating and/or cooling directly to the building or campus without requiring an intermediate heat transfer fluid. These and other variations to waterside system200are within the teachings of the present disclosure.

In some embodiments, waterside system200uses free cooling to cool the water in cold water loop216. For example, the water returning from the building in cold water loop216can be delivered to cooling tower subplant208and through cooling towers238. Cooling towers238can remove heat from the water in cold water loop216(e.g., by transferring the heat to outside air) to provide free cooling for the water in cold water loop216. In some embodiments, waterside system200switches between free cooling with cooling tower subplant208and mechanical cooling with chiller subplant208based on the current temperature of the outside air and/or the predicted future temperature of the outside air. An example of a free cooling system which can be used in waterside system200is described in greater detail with reference toFIG.6.

Cooling coil334may receive a chilled fluid from waterside system200(e.g., from cold water loop216) via piping342and may return the chilled fluid to waterside system200via piping344. Valve346can be positioned along piping342or piping344to control a flow rate of the chilled fluid through cooling coil334. In some embodiments, cooling coil334includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller330, by BMS controller366, etc.) to modulate an amount of cooling applied to supply air310.

Each of valves346and352can be controlled by an actuator. For example, valve346can be controlled by actuator354and valve352can be controlled by actuator356. Actuators354-356may communicate with AHU controller330via communications links358-360. Actuators354-356may receive control signals from AHU controller330and may provide feedback signals to controller330. In some embodiments, AHU controller330receives a measurement of the supply air temperature from a temperature sensor362positioned in supply air duct312(e.g., downstream of cooling coil334and/or heating coil336). AHU controller330may also receive a measurement of the temperature of building zone306from a temperature sensor364located in building zone306.

In some embodiments, AHU controller330uses free cooling to cool supply air310. AHU controller330can switch between free cooling and mechanical cooling by operating outside air damper320and cooling coil334. For example, AHU controller330can deactivate cooling coil334and open outside air damper320to allow outside air314to enter supply air duct312in response to a determination that free cooling is economically optimal. AHU controller330can determine whether free cooling is economically optimal based on the temperature of outside air314and/or the predicted future temperature of outside air314. For example, AHU controller330can determine whether the temperature of outside air314is predicted to be below a threshold temperature for a predetermined amount of time.

Each of building subsystems428can include any number of devices, controllers, and connections for completing its individual functions and control activities. HVAC subsystem440can include many of the same components as HVAC system100, as described with reference toFIGS.1-3. For example, HVAC subsystem440can include a chiller, a boiler, any number of air handling units, economizers, field controllers, supervisory controllers, actuators, temperature sensors, and other devices for controlling the temperature, humidity, airflow, or other variable conditions within building10. Lighting subsystem442can include any number of light fixtures, ballasts, lighting sensors, dimmers, or other devices configured to controllably adjust the amount of light provided to a building space. Security subsystem438can include occupancy sensors, video surveillance cameras, digital video recorders, video processing servers, intrusion detection devices, access control devices and servers, or other security-related devices.

Still referring toFIG.4, BMS controller366is shown to include a communications interface407and a BMS interface409. Interface407may facilitate communications between BMS controller366and external applications (e.g., monitoring and reporting applications422, enterprise control applications426, remote systems and applications444, applications residing on client devices448, etc.) for allowing user control, monitoring, and adjustment to BMS controller366and/or subsystems428. Interface407may also facilitate communications between BMS controller366and client devices448. BMS interface409may facilitate communications between BMS controller366and building subsystems428(e.g., HVAC, lighting security, lifts, power distribution, business, etc.).

Memory408(e.g., memory, memory unit, storage device, etc.) can include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory408can be or include volatile memory or non-volatile memory. Memory408can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to some embodiments, memory408is communicably connected to processor406via processing circuit404and includes computer code for executing (e.g., by processing circuit404and/or processor406) one or more processes described herein.

In some embodiments, BMS controller366is implemented within a single computer (e.g., one server, one housing, etc.). In various other embodiments BMS controller366can be distributed across multiple servers or computers (e.g., that can exist in distributed locations). Further, whileFIG.4shows applications422and426as existing outside of BMS controller366, in some embodiments, applications422and426can be hosted within BMS controller366(e.g., within memory408).

Building subsystem integration layer420can be configured to manage communications between BMS controller366and building subsystems428. For example, building subsystem integration layer420may receive sensor data and input signals from building subsystems428and provide output data and control signals to building subsystems428. Building subsystem integration layer420may also be configured to manage communications between building subsystems428. Building subsystem integration layer420translate communications (e.g., sensor data, input signals, output signals, etc.) across a plurality of multi-vendor/multi-protocol systems.

Expired Operational Certificate Recovery

Referring now toFIG.5, a schematic illustration of a process500of mutual TLS authentication of operational certificates between a first device520and a second device510in a BMS, such as BMS400, is shown according to an example embodiment. The devices510,520may include one or more processors and one or more computer-readable storage media having instructions stored thereon. The one or more processors may be configured to execute the instructions to perform the actions and processes described herein. A user interface device, such as client device368, may interface with the devices510,520to provide instructions to the devices510,520and may provide a user interface to the user. The first device520may be communicably connected to the second device510. The first device520and second device510may communicate securely using a protocol such as TLS. As a non-limiting example, the devices510,520may communicate via secure WebSocket connections as of RFC 6455 and TLS V1.3 as of RFC 8446 for BACnet/SC connections (protocols established by the Internet Engineering Task Force), which provide for confidentiality, integrity, and authenticity of BACnet Virtual Link control (BVLC) messages transmitted across the connection.

The storage media (e.g., memory, memory unit, storage device, etc.) of the devices510,520can include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described herein. The storage media can include volatile memory or non-volatile memory. The storage media can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. The storage media may be communicably connected to one or more processors and includes computer code for executing one or more processes described herein.

At operation501, the second device510and the first device520their respective device operational certificates515,525to each other for validation. At operation502, the second device510and first device520each perform a first validation check551. The second device510validates that the first device operational certificate525is well formed, and the first device520validates that the second device operational certificate515is well formed. At operation503, the second device510and first device520each perform a second validation check552. The second device510validates that the first device operational certificate525is active as of the current date and not expired, and the first device520validates that the second device operational certificate515is active as of the current date and not expired. At operation504, the second device510and first device520each perform a third validation check553. The second device510validates that the first device operational certificate525has not been revoked, and the first device520validates that the second device operational certificate515has not been revoked. At operation505, the second device510and first device520each perform a fourth validation check554. The second device510validates that the first device operational certificate525is directly signed by one of the locally configured Certificate Authority (CA) certificates, and the first device520validates that the second device operational certificate515is directly signed by one of the locally configured CA certificates. Each device will trust certificates from a list of one or more trusted CAs stored on the device, and will not trust certificates signed by other CAs. The validation checks551-554may occur in any order or simultaneously. Once the validation checks551-554are complete, the first device520can communicate with the second device510, as shown in operation506. Additional validation checks may be performed depending on the needs of the user, such as checks for Common Name, Distinguished Name, Subject Alternate Names, etc.

Operational certificates can be valid for a limited period of time. When a device operational certificate is close to the expiration date, the operational certificate needs to be replaced with a new operational certificate that has an updated expiration date. BMS administrators are generally provided with at least 60 days' notice of an impending operational certificate expiration. However, even with this advance notice, operational certificates are often allowed to expire before being replaced. For example, a device may be offline when the operational certificates of the other devices are replaced. For example, referring still toFIG.5, in the event the first device operational certificate525is expired, the second device510will fail to validate the certificate525during the second validation check552. This check will fail on any device that the first device attempts to communicate with, and communication between the first device520and the rest of the BMS with be prohibited. Depending on the device, this can cause serious issues in the BMS. Therefore, it would be advantageous for a user to instruct the devices in the system to accept specified expired certificates in order to keep the BMS running properly.

FIGS.6A-6Cillustrate a process for instructing devices in a BMS to accept an expired operational certificate according to an example embodiment.FIG.6Ashows a portion of a BMS1100including four devices: (1) a first field device1102with a first operational certificate1104including a first fingerprint1106; (2) a second field device1112with a second operational certificate1114including a second fingerprint1116; (3) a supervisory device1122with a third operational certificate1124including a third fingerprint; and (4) a sensor1132with a fourth operational certificate1134including a fourth fingerprint1136. A “fingerprint” (or hash) is a number or string generated from a longer string of text (e.g., raw text, a block of computer code, a computer file, etc.). A hash is smaller than the hashed message and is generated by a formula that makes it unlikely that other messages will produce the same hash. Hashes are used with digital signatures to provide additional security in a memory efficient manner since hashes represent a large amount of data as a smaller numeric value. Thus, the hash of the operational certificate is able to identify the operational certificate in a memory-efficient and secure manner.

The first field device1102is configured to communicate with each of the other devices1112,1122,1132, and the supervisory device1122is also configured to communicate with the second field device1112. The devices that are configured to communicate with each other attempt a TLS handshake. The TLS handshake may be process500described above or a similar process for validating operational certificates. In this example, the first operational certificate1104of the first field device1102is expired. Therefore, the TLS handshake between the first field device1102and the other devices1112,1122,1132will therefore fail and the first field device will not be permitted to communicate with the other devices1112,1122,1132. Both the supervisory device1122and the second field device1112have valid operational certificates1124,1114, so the TLS handshake between the supervisory device1122and the second field device1112will succeed and the supervisory device1122and the second field device1112will be permitted to communicate with each other.

FIG.6Bshows the portion of the BMS1100as well as a user1150and a user interface device1140. The user1150may receive information from the user interface device1140indicating that the first operational certificate1104of the first field device1102has expired. The user1150may input a command to the user interface device1140instructing it to push an allowable expired list1155to each of the devices1112,1122,1132. The allowable expired list1155contains the fingerprints of any expired operational certificates that the user would like the devices to accept. In this example, the allowable expired list1155would include the first fingerprint1106. Thus, the devices1112,1122,1132, would accept the expired first operational certificate1104from the first field device. In some embodiments, different allowable expired lists1155may be pushed to different devices, depending on the arrangement of the BMS.

FIG.6Cshows the portion of the BMS1100after the allowable expired list1155has been pushed to the supervisory device1122, the second field device1112, and the sensor1132. Because the first fingerprint1106is on the allowable expired list1155, the TLS handshakes between the first field device1102and the other devices1112,1122,1132are successful and communication between the first field device1102and the other devices1112,1122,1132is permitted. The user1150may define how long the allowable expired list1155should remain on the devices1112,1122,1132via the user interface device1140. Alternatively, the user1150may push the allowable expired list1155to the devices1112,1122,1132via the user interface device1140and may remove or alter the list via the user interface device1140as needed. Generally, expired operational certificates should be accepted only for a limited time and should be replaced by a new certificate when possible. A user1150may use a user interface device1140to connect to a device with an expired operational certificate, such as field device1102, with a new certificate. The user interface device1140and the field device1102must perform mutual authentication to communicate with each other. The field device1102may authenticate a certificate from the user interface device1140, and the user interface device1140must authenticate the operational certificate1104from the field device1102. The user interface device1140may be configured to accept the expired operational certificate1104as valid. Once the certificates are authenticated, the user interface device1140may communicate with the field device1102and the user interface device1140may replace the expired operational certificate1104with a new operational certificate. It should be understood that the operations of the process described inFIGS.6A-6Cmay take place in different orders or simultaneously, or make take place at different times. Specifically, the BMS may operate using devices with expired certificates for days or weeks before replacement operational certificates are delivered to those devices.

In some circumstances, a user interface device1140may not be able to communicate directly with a device and must communicate with the device through another device. For example, a field device, such as field device1102, may only be able to communicate with a user interface device1140through a supervisory device, such as supervisory device1122. In that case, the supervisory device1122may be instructed to accept the expired operational certificate1104of the field device1102as valid using the methods described herein, thus permitting communication between the supervisory device1122and the field device102. Then, the user interface device1140may instruct the supervisory device1122to replace the expired operational certificate1104with a new certificate.

FIG.7illustrates a process600for replacing an expired operational certificate on a device according to an example embodiment. At operation603, the supervisory device610performs a second validation check552on the first device operational certificate525that has been sent to it by the first device520. In this case, the second validation check552has failed because the first device operational certificate525has expired. Each device510,520may perform additional validation checks to determine that the second validation check522is the only validation check that failed, indicating that the only issue preventing communication between the devices510,520is that the first device operational certificate525is expired. At operation604, a user650may log into a user interface device640. The user650may enter commands into the user interface device540instructing the user interface device640to send a command to the second device510to accept the expired first device operational certificate525. The user interface device640may push a list of allowable expired certificate fingerprints to the second device510that includes the fingerprint of the first device operational certificate525. At operation605, the engine again performs a second validation check552, this time also checking the allowable expired list, and accepts the fingerprint of the expired first device operational certificate525as if it were unexpired.

In this example embodiment, the first device520is not capable of communicating directly with the user interface device640. At operation606, the user650, via a user interface device640, may load a replacement device operational certificate625to the first device520. The user interface device641may be the same device as user interface device640, or may be a different device. For example, the user interface device640may be capable of instructing devices in the BMS to accept expired operational certificates, but may not be configured to replace expired operational certificates with new operational certificates. If that is the case, the user interface device641may be a different device that is able to replace the expired operational certificates. The replacement device operational certificate625may be stored on the first device520and may replace the original first device operational certificate525. At operation607, the user650may enter a command into the user interface device640to reset the connection between the first device520and the second device510by closing and reopening the connection. The TLS protocol and other security protocols may require this reset in order for the second device510to accept the replacement device operational certificate625. The second device operational certificate515may remain valid during the replacement of the first device operational certificate525and the resetting of the connection. The first device520may then perform the validation checks551-554on the second device operational certificate515and the engine may perform the validation checks551-554on the replacement device operational certificate625, as described in process500. Communication between the second device510and the first device520may then be allowed, as shown in operation608.

FIG.8is a schematic diagram of a workflow and object interaction700between a supervisory device710and a plurality of field devices, e.g., field devices801-803, according to an example embodiment. A supervisory device may be connected to any number of field devices. Each field device includes a device object and an Operational Certificate Object (OCO), each containing a fingerprint, or hash, of the device operational certificate. For example, field device801includes a device object811and an OCO821which share fingerprint831. The supervisory device710includes a plurality of device mappers, each mapped to one field device. For example, device mapper851is mapped to field device801, device mapper852is mapped to field device802, and device mapper853is mapped to field device803. Additional field devices connected to the supervisory device710would each require an additional device mapper.

In this example, each device mapper includes a known fingerprint that the device mapper compares to the fingerprint received from a field device to confirm that the field device is permitted to connect to the BMS. For example, device mapper851includes known fingerprint861. When a field device is successfully mapped to a supervisory device, the device mapper will receive the fingerprint, or hash, of the operational certificate for the field device. The device mapper compares the known fingerprint to the fingerprint it receives from the field device. If the fingerprint from the field device matches the known fingerprint and the fingerprint is not expired, the field device is permitted to communicate with the supervisory device. For example, device mapper852has compared the fingerprint832of its corresponding field device802to its known fingerprint862and determined that the fingerprints match. Similarly, device mapper853has determined that fingerprint833from field device803matches known fingerprint863. Accordingly, field devices802and803are permitted to communicate with the second device510.

However, if the field device certificate has expired, the supervisory device will inspect the fingerprint, determine from the fingerprint that the operational certificate is expired, and the reject the connection. For example, device mapper851compares known fingerprint861to the fingerprint831that it receives from the field device801and determines that they match, but refuses the connection because the fingerprint indicates that the operational certificate has expired. The field device801will then be prohibited from communicating with the supervisory device710. The field device801may appear offline to a user via a user interface (e.g., user interface900) and an attribute list may indicate to the user that the reason the field device is offline is because the operational certificate is expired. When a user sees an indication that one or more of the field devices is offline due to an expired operational certificate, the user may instruct the supervisory device710to accept expired operational certificates,

FIG.9is a schematic representation of a workflow and object interaction800during the CPR diagnostic process, according to an example embodiment. The user650sends a command via user interface device640to each device mapper that is indicating a field device is offline. For example, the user650inFIG.8has selected device mapper851. Device mapper851can send its known fingerprint861to the Libwebsockets (LWS) layer870of the supervisory device710. The LWS layer870is a third-party library that enables a websocket connection between the supervisory device710and the field devices. For example, the LWS layer870may form a websockets connection with the LWS layer880of field device801. The LWS layers870,880may each be connected to a WOLFSSL library871,881, or any another embedded SSL/TLS library containing a cryptography engine capable of securely decoding the fingerprints. The LWS layer870includes a callback handler that will then compare the known fingerprint to the fingerprint received from the corresponding field device. For example, LWS layer870includes a callback handler that can compare the known fingerprint861to the fingerprint831received from field device801.

If the LWS callback handler determines that the fingerprint from the field device otherwise matches the known fingerprint stored in the device mapper, the LWS callback handler can then determine the callback reason, i.e., the reason why the field device connection was rejected. If the LWS callback handler determines that the field device connection was rejected due to an expired certificate, the supervisory device710can relax the date constraint and accept the expired certificate. The supervisory device may remove the expiration date constraint entirely or may adjust the expiration date by a fixed amount of time. For example, the supervisory device710may extend the expiration date by only one month in order to accept only operational certificates that have recently expired (i.e., in the past month). The device mapper will then indicate to the user that the field device is back online. The user may then instruct the supervisory device710to load a replacement device operational certificate onto the field device. BACnet and other security protocols may require that connections between the supervisory device710and any field devices with replacement operational certificates be closed and re-established to ensure that the replacement device operational certificate is being used. The field device801may temporarily appear offline to the user while the connection is reset. Once the new connection has been established, the known fingerprint in the device mapper is replaced by a new fingerprint corresponding to the replacement device operational certificate. The device operational certificate fingerprint should then match the known fingerprint, and the field device801can communicate with the supervisory device710. The engine will then indicate that the field device is online. It should be understood that the embodiment shown inFIG.9can be performed on any device capable of communicating with the user interface device640, and is not limited to supervisory devices.

Referring toFIG.10, a user interface900associated with BMS400and the processes described herein is shown, according to an example embodiment. User interface900may be displayed on a screen of a user interface device, such as user interface device640or client device368. User interface900may include a plurality of device icons951, each representing a device in the BMS. Additional device icons951may appear below the icons shown when a user scrolls down on the GUI. The device icons951may include various information about the corresponding field device, for example, the name of the field device, the model number of the field device, the system the field device is configured to control (e.g., HVAC, Electrical, Fire Detection, Lighting, etc.), the location of the field device, the device operational certificate expiration date, etc. In some embodiments, the user may be able to click or select a device icon951to see additional information about the corresponding field device, adjust settings or enter information relating to the corresponding device, disconnect or reconnect a device, replace the operational certificate of the device prior to the expiration date, or perform other functions relating to the selected device. In some embodiments a user may be able to select a device icon951corresponding to a device with an expired operational certificate and instruct the other devices in the BMS to enable communication to the device or with the expired certificate. The user may be replace the expired certificate once a new one is available.

Each device icon951may have a connection status indicator icon960that signals whether or not the device corresponding to that device icon951is able to communicate with the other devices in the BMS. A restore connection icon970may appear next to the device icon951of a device that is unable to communicate with the other devices. A user may click or select the restore connection icon970in order to add the fingerprint of the operational certificate of field device corresponding to the device icon951to the allowable expired list1155, according to the embodiments described above. The allowable expired list1155may then be pushed to the other devices in the system, instructing the devices to relax or ignore the expiration date of operational certificate fingerprints on the allowable expired list1155. The other devices may then accept the fingerprint of any expired operational certificates that are on the allowable expired list1155and communication may be restored.

Configuration of Example Embodiments