*3.3. Test Results*

#### 3.3.1. Test Results of "Rogue Zone" Algorithm

The "rogue zone" auto-correction algorithm worked as expected on AHU01 and AHU02 during the testing period. Figure 6 shows the results of the values for the requests and ignored requests calculated on 4 March. The two heat maps in Figure 6 depict each zone (in the vertical axis) plotted against the time of the day, for a single day. For each zone, the darker areas show when the requests (red) and ignored requests (blue) happened during the day. *R*, *Irouge*\_*zones*, and *R* were reevaluated every five minutes. Taking 11:00 a.m. as an example, the vertical line marks the values of *Ri*, *Irogue*\_*zone*\_*i*, *R*, *Itotal*, and *R* at 11:00 a.m.: eight zones (i.e., Rm 4107, Rm 411, Rm 4113, Rm 4203B, Rm 5113, Rm 5115, Rm 5116, and Rm 5204A) sent requests ( *R* = 8), three zones (i.e., Rm 4107, Rm 5113, and Rm 5116) were identified as rogue zones (*Irogue*\_*zones* = 3), and two additional zones were ignored by default (*Ide f ault* = 2), summing up to a total of five zones ignored (*Itotal* = 5). *R* is therefore equal to 3, based on Equation (3). This test confirmed that the system correctly calculated and implemented the modified requests, ignoring the rogue zones.

**Figure 6.** Zone requests per zone (upper left), the ignored requests per zone (upper right), the sum of the requests, the total of ignored requests and the net requests for all the zones of AHU01 on 4 March 2020. The vertical line marks 11 a.m. on all the plots.

#### 3.3.2. Test Results of "Improve AHU SAT Setpoint Reset" Algorithm

The auto-correction algorithm "Improve AHU SAT setpoint reset" successfully changed the SAT setpoint of AHU01 and AHU02 in the BAS. As shown in Figure 7, the SAT setpoint changes followed the routine described in Section 3.2. The supply fan was on for the whole time, since this AHU serves laboratory areas. When *R'* was larger than zero starting at 10:05 a.m., the algorithm slowly reduced the SAT setpoint by 0.06 ◦C for each request every five minutes. Starting at 11:50 a.m., the *R'* remained at zero and the routine slowly increased the SAT setpoint by 0.12 ◦C every five minutes until it reached SATmax (18.3 ◦C). The SAT setpoint remained at SATmax until *R'* was larger than zero at 14:50 p.m. Then, the SAT setpoint again slowly decreased when *R'* was larger than zero and slowly increased when *R'* was zero.

Because both the original and corrected logic used feedback loops, a direct comparison of the two was not possible without modeling the dynamic behavior of the system or collecting enough data to perform a system-level evaluation. However, since the original controller was still active (for backup purposes) we could qualitatively compare the time at which each algorithm would start reducing the SAT setpoint in the morning. Figure 8 shows this comparison for two consecutive days in AHU01. The red line represents the corrected setpoint that was calculated by the algorithm and the blue line was the actual temperature that tracked the setpoint. The green line depicts the original logic. As highlighted by the text, the original logic would try to reduce the temperature much earlier than the corrective algorithm. This behavior was consistent across the testing period for both AHUs. For AHU01, during 14 days out of the 34 days, the old logic started earlier, while during the other 20 days the system did not require cooling. Conversely, for AHU02, during 13 days the old logic

started earlier, during one day it started later, and the other days it did not require cooling (the test was conducted during a mild spring). Overall, the preliminary test was successful. It showed the uninterrupted operation of the two algorithms in two AHUs for more than a month. The SAT tracked the new setpoint throughout the whole testing period. The new control sequence did not cause any occupant complaints, and it worked more efficiently than the previous one, although a precise savings estimate was beyond the scope of the test.

**Figure 7.** The SAT setpoint of AHU01 after the execution of the auto-correction algorithm (4 March 2020).

**Figure 8.** Comparison of the new and the old setpoint control strategies in AHU01 during 3–4 March 2020.

#### **4. Discussion: Implementation Challenges and Solutions**

The commercial partners faced a number of challenges when implementing the auto-correction algorithms into the FDD tools. We organized these issues under four areas: (1) developing a secure two-way communication between the FDD tool and the BAS; (2) incorporating operator approval; (3) managing the customizations necessary to the specific BAS/site installation; and (4) managing the potential conflict between the auto-correction and the BAS control actions. This section describes these challenges, as well as the solutions that the partners came up with to mitigate them.

The di fferences in the solutions described below also stemmed from di fferent FDD software architectures, as well as di fferent BAS network setups across the implementation partners. The FDD products developed by the two partners were based on software platforms that ran from the cloud with centralized fault libraries and analytics engines. These companies used additional hardware and software installed on site to collect data and send it to the cloud. A third implementation partner was the distributor of a third-party software and developed custom algorithms for various customers. This software ran on the local BAS network and had direct access to it, allowing access to external users via a virtual private network connection.

#### *4.1. Develop a Secure Two-Way Communication Between the FDD and the BAS*

Opening a two-way communication between the FDD system and the BAS was a challenge seen across all project partners implementing fault auto-correction into their FDD product environment. FDD tools typically read operational data from the BAS, run analytics and flag faults on the software interface. Often, they do not have capabilities to write commands directly onto the BAS. As indicated in Figure 1, the FDD tool commonly collects operational data using three pathways: (1) from the BAS server database, (2) from a central BAS server via API and (3) directly via the BACnet IP network. The first pathway prevents the FDD tool from writing back to the control system, therefore it cannot be used to implement auto-correction procedures. The second one requires BAS-specific interfaces; thus, implementers tend to avoid it. For this reason, when expanding the one-way interface to two-way communication, all the partners selected the third pathway to write back directly via the BACnet IP network.

The project partners mitigated the two-way communication challenge by upgrading their FDD system infrastructure. Figure 9 illustrates the solutions for the two cloud-based FDD systems. The solid line shows the original infrastructure, and the red dashed line shows the upgrade. In the first cloud-based FDD case (Figure 9a), the BACnet stack (a software library allows users to add a native BACnet interface to talk to the devices or applications in the BACnet network) of the FDD data acquisition device was updated to include a "write" function. The local data acquisition device was also updated to make API requests to the cloud FDD platform to retrieve the auto-correction command information. This enabled the FDD system to send the auto-corrective command to the local device and then to the writable properties used to control the BAS. In a cloud-based FDD system of another partner (Figure 9b), the current BACnet library already had writing capabilities. To enable secure communication with the cloud, the system architecture was changed. The standard data acquisition device was paired with a new field device (an auto-correction execution device) specifically designed to execute the new routines and log the interaction with the BAS. The cloud FDD engine initiated the auto-corrective command onto the auto-correction execution device. The device then executed the commands onto the BAS BACnet network and reported back the results to the cloud FDD engine. The BAS data were still acquired by the existing FDD data acquisition field device and delivered to the cloud FDD engine. The third on-premise FDD system was already capable of writing commands via BACnet. It only needed to change a setting in the BAS to authorize the changes.

**Figure 9.** Two-way communication infrastructure for (**a**) the cloud-based FDD system 1, and (**b**) the cloud-based FDD system 2.
