HEATING, VENTILATION, AND AIR CONDITIONING FAULT DETECTION USING THE FUZZY JESS TOOLKIT. A Thesis. Presented to

Transcription

1 HEATING, VENTILATION, AND AIR CONDITIONING FAULT DETECTION USING THE FUZZY JESS TOOLKIT A Thesis Presented to The Graduate Faculty of The University of Akron In Partial Fulfillment of the Requirements for the Degree Master of Science Peter Knall May, 2014

2 HEATING, VENTILATION, AND AIR CONDITIONING FAULT DETECTION USING THE FUZZY JESS TOOLKIT Peter Knall Thesis Approved: Accepted: Advisor Dr. Kathy Liszka Dean of the College Dr. Chand Midha Co-Advisor Dr. Chien-Chung Chan Dean of the Graduate School Dr. George R. Newkome Committee Member Dr. Michael Collard Date Department Chair Dr. Yingcai Xiao ii

3 ABSTRACT Research into automated methods for detecting and diagnosing faults in heating, ventilating, and air conditioning systems has been an ongoing process for many years and, as a result, there have been many different methods developed for that purpose. A basic fault detection system is presented based on aspects of several of those approaches using performance index calculations, statistical process control methods, fuzzy logic, and rule-based inference. Factors that drive research in fault detection and diagnosis in the Heating, Ventilation, and Air Condition (HVAC) industry are discussed. A simple HVAC controller is presented with a discussion of the faults the control may experience. These faults are classified into categories, which are then used to develop a test procedure for the fault detection system. The fault detection system is then presented in three modules: preprocessing of sensor data, conversion to fuzzy values, and detection using the JESS inference engine. Sensor data is preprocessed into a time-based performance index based on a departure from setpoint and an exponentially weighted moving average calculation. The conversion of the error values into fuzzy values is then discussed. Once the error values are calculated, the fuzzy error values and controller data are applied to expert rules through the JESS inference engine to detect control faults. This model is tested in two phases. First, data obtained from simulated faults is used during phase one. Phase two applies the fault detection system to a small office building. Finally, the results of the two tests are discussed. iii

4 DEDICATION Dedicated to my wife, Laurie, for the years of support, encouragement, and sacrifice that made this opportunity possible. iv

5 TABLE OF CONTENTS Page LIST OF TABLES... vi LIST OF FIGURES... vii CHAPTER I. INTRODUCTION... 1 II. EQUIPMENT SEQUENCE OF OPERATION III. PREVIOUS ATTEMPTS IV. SELECTION OF FAULTS V. THE FAULT DETECTION SYSTEM VI. PHASE ONE TEST RESULTS VII. PHASE TWO TEST RESULTS VIII. CONCLUSIONS IX. FUTURE WORK BIBLIOGAPHY APPENDICIES APPENDIX A: VVT CONTROL STATUS OBJECT CODE LISTING APPENDIX B: FAULT DETECTION CODE LISTING v

6 LIST OF TABLES Table Page 1. Potential Symptoms of Select VVT Failures Jess Rule Salience Sensor Faults Phase 1 Test Results vi

7 LIST OF FIGURES Figure Page 1. VVT Control Block Diagram Diagram of the Fault Detection System Temperature Error as Room Temperature Exceeds Setpoint Airflow Error as Actual Airflow Exceeds Setpoint CSV File Architecture Fault Detection Model Fuzzy Membership Functions Main Processing Loop Temperature Sensor Failed High Results Temperature Sensor Failed Low Results Temperature Sensor Misconfigured Results Low Temperature Control Error Trends High Temperature Control Error Trends Low Airflow Control Error Trends High Airflow Control Error Trends VVT-5 Fault Detection Trend Log VVT-6 Normal Operating Logs vii

8 CHAPTER I INTRODUCTION Research into automated methods for the detection and diagnosis of faults in heating, ventilating, and air conditioning (HVAC) systems has been an ongoing process for many years. This research has resulted in the development of many different methods for that purpose. There are many reasons that have driven the development of automated Fault Detection and Diagnosis (FDD) systems on HVAC equipment, reasons which have become increasingly prevalent with the ongoing rise in energy costs and the drive for many organizations to lower their operating budgets (IEA Annex 25, 1996) (House, Lee, & Shin, 1999). 1. Reduced gas, electricity, and water usage 2. Reduced maintenance cost and equipment downtime 3. Increased comfort and air quality 4. Increased equipment life and reliability 5. Mitigation of the increased complexity of the building automation system The rising cost of energy has caused many organizations to review their HVAC equipment on several different levels. For many years, the operational cost of conditioning buildings was relatively low as compared to other costs due to the lower price of natural gas, electricity, and water. As these prices have increased, more emphasis has been placed on the operation and construction of the building s HVAC equipment. For example, many have moved to boiler systems that are more efficient, used more aggressive scheduling to operate equipment only when the building is normally occupied, and employed various meters to measure gas, 1

9 water, and electricity usage. To reduce energy costs, fault detection methods are used to detect higher than normal rates of energy usage that can be caused by equipment in need of maintenance, abrupt equipment failures, and improper equipment usage by the occupants. Equipment in need of maintenance can also be detected through the use of trained algorithms to detect a reduction in efficiency. The required maintenance can then be scheduled for a more convenient time than would be possible if the maintenance were scheduled to repair an abrupt failure or as a result of occupant complaints. In addition, competent operators can be scheduled during the equipment downtime to ensure that only the minimum amount of time to perform the maintenance is necessary, increase the likelihood that it is performed correctly, and allows the overall cost of the repair to be reduced (House, Lee, & Shin, 1999). Air quality and comfort can be negatively affected by improper system operation. FDD systems ensure the required number of air changes is delivered to a building, and that the temperature of each room is maintained within setpoint. Degradations in equipment performance can cause room temperatures to become uncontrollable and negatively affect occupant health and comfort. Equipment life and reliability and be increased through the use of an effective fault detection and diagnosis system (Hou, Lian, Yao, & Yuan, 2006). As imminent failures and gradual degradations in system performance are detected, maintenance and repairs can be performed to prevent excessive equipment downtime and correct inefficient behavior. In addition, information about equipment performance and room conditions is infrequently employed by the maintenance team due to the significant amount of time and experience required to manually detect and diagnose these problems (Norford, Wright, Buswell, & Luo, 2000). The delay in fault detection can be reduced by using automated algorithms for detection and diagnosis which incorporate this training. 2

10 Technological developments have caused modern building automation systems to advance, and in many cases, have become difficult for the average operator to understand. Control programs are usually only designed to handle simple or abrupt faults (IEA Annex 25, 1996). More complicated fault analysis is performed by fault detection systems to assist the operator to diagnose faults too subtle for simple alarm strategies or manual trend analysis (Schein & Bushby, A Hierarchical Rule-Based Fault Detection and Diagnostic Method for HVAC Systems, 2006). Many different methods to detect and diagnose faults in HVAC systems have been developed. Each of them, however, experience a common set of obstacles to overcome: 1. Availability of Historical Data and Test Facilities during development 2. Lack of standard sequences for systems and equipment 3. Lack of sensor redundancy and coincidence 4. First cost considerations 5. Simple interface for User interaction 6. System level analysis 7. FDD rating criteria 8. Data transmission and computation requirements In many cases, the historical data of HVAC system in a failure mode either does not exist or is not complete. This data is used to train advanced FDD systems and is extremely difficult to simulate. In addition, it is often not feasible to cause a complex HVAC system to operate in a fault mode to collect the data (Norford, Wright, Buswell, & Luo, 2000). When an HVAC FDD system is being researched and developed, one of the most significant problems that are encountered is a lack of standardized sequences for equipment. Even for the relatively simple Variable Volume and Temperature (VVT) control, development of an FDD system that is specific to that system can be difficult since a non-portable sequence of 3

11 operation can result from small changes in the control strategy. When general operational sequences are used, the benefit is limited due to operational differences between identical HVAC equipment caused by changes in location, building factors, and differences in usage. To compensate for these differences, general HVAC FDD strategies can be used to address unique system complexities. These generalities, however, reduce the sensitivity of the detection and diagnostic algorithms. FDD systems have been developed for many other processes such as nuclear power plants, chemical processing controllers, and airplanes control systems. Unlike HVAC systems, these systems also have an added safety factor that must be accounted for in their design (Braun, 1999). These safety factors would typically include sensor coincidence and redundancy. A fault must be detected by more than one detector before action is allowed by the coincidence system. A sensor fault is detected when data from other redundant sensor are compared and one is found to be in a fault condition. Any additional sensors required to satisfy coincidence and redundancy are added to the system during the design phase of the project. Since FDD is not usually taken into account during the design phase of an HVAC system, these sensors are not added into a typical HVAC system. The result is that a fault may be masked or falsely indicated due to a sensor failure. Automatic detection of these conditions is very difficult due to the lack of available sensor data to support or refute the indication. Many factors are considered when looking at first-cost of an FDD system. Cost of the FDD system s development, installation, testing, and operator training are considered and can easily cause the system to becoe very expensive. For example, due to a system s complexity, an engineer may be required to spend several hours on large HVAC equipment such boiler systems, chilled water systems, and air handlers. When combined with the differences in operational sequences and usage, each FDD system is required to be specifically tuned each time it is installed (IEA Annex 25, 1996), (House, Lee, & Shin, 1999). The amount of time and testing that is required for these systems can cause these FDD systems to be financially infeasible. 4

12 The usefulness of an FDD system will be compromised if the system cannot be easily used by the operator. Building Automation Systems (BAS) are used by the average operator only to schedule building usage and to monitor equipment performance (IEA Annex 25, 1996). Advanced knowledge of HVAC sequences and FDD techniques is beyond the scope of the operator s duties and an easy to use interface is required to ensure successful use of the system. Several different faults can be diagnosed with identical indications at a particular piece of equipment. This problem is particularly emphasized due to the relatively low number of sensors designed into the system. To assist in fault diagnosis, the indications of several pieces of equipment as well as the system must be analyzed. More specific and reliable diagnoses are produced with the inclusion of additional information and enhanced system level FDD algorithms. While much research has been done on FDD for HVAC systems, standard methods for evaluating the performance of FDD system are not well established. One of the more common methods is a low false detection rate and the number of correct diagnoses out of a set of test data. This metric is widely accepted because most operators will stop using an FDD system if the false positive rate is too high. Many benefits to using an HVAC FDD system are focused on cost saving, however methods for reporting savings specifically from an FDD system are not well established. Other factors that are considered are the amount of training required to use the system, computational resources required, and relative simplicity of the system (House, Lee, & Shin, 1999) (IEA Annex 25, 1996). Equipment control modules are not equipped with tools for the operator to use to evaluate trends, or to take advantage of existing or future tools to perform advanced information analysis. Any manual or automatic fault detection that uses controller data requires the information to be transferred to a central database. While normally reliable, this data transfer is further complicated by the nature of the network infrastructure. Data that is required to be collected in a central location for analysis can be lost during transmission due to excessive network traffic, changes in the network structure, equipment failure, or other unforeseen reasons. 5

13 However, with an increase in the size of the HVAC system, higher requirements in the computational power of database and analytics machine and the network infrastructure are seen. In order to support a scalable HVAC Fault Detection system, Schein et al. (2003) and Seem et al. (2000) suggested some of the computational requirements be handled at the controller level. With these factors taken into account, the ideal FDD system would general enough to handle most HVAC fault conditions with an interface simple enough to allow the average maintenance personnel to tune the system for their specific equipment. In addition, the system would be sensitive to the lack of sensor redundancy and provide a relative belief factor for each fault detected. Finally, system level faults are detected and these faults prevent fault detections from equipment lower in the hierarchy and the resulting notifications to the maintenance personnel. Not all of these factors are considered here. The development of a simple yet effective user interface, the consideration of first cost, FDD rating criteria, and the lack of sensor data and redundancy are considered to be beyond the scope of this thesis and could easily each be projects on their own. The development of a system to accommodate a wide variance in the sequence of operation for a particular class of equipment was considered of primary importance and is chosen as the focus of the FDD system. In addition, a portion of the FDD rules are focused on detecting system level faults. Finally, the data and computational requirements of the live system are taken into account during the design of the FDD system. With these three factors taken into consideration the design of the fault detection system consists of four building blocks: Performance Index calculations, Statistical Process Methods, Fuzzy Logic, and a Rule-Based Inference Engine. In order for a fault condition to be detected, controller sensor readings are compared to their respective setpoints to produce a performance index. This method is not only easily understood, but common among the FDD methods researched. Any one or all of several different performance index calculations could have been chosen. These methods are described by Seem et al. (2000): process error, absolute value of process error, process output, absolute 6

14 value of change in control output, control input, duty cycle, and number of starts, stops and reversals. The process error calculation was chosen because the calculation is simple enough to be handled at the controller level and relatively easy to understand. The process error is also general in nature and can be applied in common situations with a larger focus on purpose instead of function. Calculating the performance index provides an indication of the present state of the system, however information about the system s past is not provided. In order to provide the fault detection system with sensitivity to time, Seem et al. (2000) applied the performance index to an Exponentially Weighted Moving Average (EWMA) statistical process control. This method is well established, consumes little memory, and simple enough to perform in the control module. The use of this method resulted in three key benefits. First, the use of a EWMA to convert the Fault Detection system from a time base to a frame base allowed the individual records to be evaluated independently without a dependency on the previous or next record. Also, the overall network traffic is reduced by the conversion from a performance index into a EWMA since fewer data points are required to contain the same information. Inside the controller, the EWMA is calculated every minute, and the result is sent to the database every 10 minutes. If the EWMA is calculated with a general purpose machine requesting the data from the database, ten times more data must be transmitted to the database from the controller. Also, if data is lost and is not saved by the database, the result of the EWMA calculation will be inaccurate. System scalability is enhanced by a shift in the preprocessing load from the general use computer to the control modules. The resulting of the EWMA calculations are converted to a Fuzzy Values. These values allow for the use of everyday words to describe the error value instead of literal numbers. The use of common language results in logic rules to be easier to read and provide the error ranges with an inherent meaning. 7

15 The fuzzy values are used in a rule-based inference engine to detect faults. A rule based structure for a hierarchical rule based FDD system is chosen by Schein and Bushby (2006) for this reason. They reasoned that the ability for the operator to understand and modify FDD rules specific for their equipment is of vital importance if the system was to be used by the maintenance team. In addition, a hierarchical decision making framework is used to detect and diagnose equipment level and system level faults. This combination produced a system that has sufficient adaptability and flexibility to be useful by the operator. Several other methods were also researched. Wu and Sun (2011) described a method to perform spatial and temporal fault detection on a system level using an energy flow model. Their method accounted for changes in outdoor air temperature, spatial relationship of the rooms, room occupied and unoccupied loads, and the usage of the room. Schien and Bushby (2006) proposed a rule based method for system level FDD. Equipment in the hierarchy would disable FDD alarms in other equipment higher or lower in the hierarchy based on the root cause. For example, if the supply air temperature of an AHU is significantly higher than setpoint, then FDD alarms in the lower level zone controllers are disabled. Individual equipment fault detection is performed using two different methods. FDD in AHUs is performed using energy balance equations and rule based logic, while FDD in the zone controllers is performed using the cumulative sum (cusum) statistical control method. Wang et al. (2009) suggested a method of system level FDD that is divided into two parts. The first portion performs FDD based on principal component analysis, then the initial results are provided to the second portion whose FDD is based on comparing the input with performance indexes. An FDD method based on electrical consumption and first principle analysis is discussed by Norford et al. (2000). Many different FDD models are presented by the International Energy Agency Annex 25 (1996), as well as a detailed discussion on potential faults and their relative ranking based several surveys of various expert groups. 8

16 The result of the fault detection system after the data has been processed will be the determination of normal operation conditions, sensor faults, flow control faults, temperature control faults, or system level flow and temperature control faults. These results are evaluated by the time to alarm, accuracy of detection, and the amount of information reported. 9

17 CHAPTER II EQUIPMENT SEQUENCE OF OPERATION A Variable Volume and Temperature (VVT) system is used for testing the HVAC FDD algorithms due to its simplistic design. VVT systems are widely used in small to medium sized buildings, and are usually supplied as a packaged system. Comfort is maintained in the building by varying the amount and temperature of the air supplied by the air hander unit (AHU). The room air temperature is maintained through the combination of supply air temperature control from the AHU and the amount of air supplied to each room. The temperature of the individual rooms is controlled by regulating the amount of air being supplied from the AHU. To maintain the air quality for building occupants a minimum amount of airflow is supplied to each room. This air is used to reduce the products of off-gassing from the building as well as maintain the CO2 and humidity levels for occupant comfort. Heating and cooling air is controlled to the room as follows (Figure 1) (Seem, House, & Monroe, 2000). 1. Room temperature is maintained between a heating and cooling setpoint a. When the temperature of the room is above the cooling set point i. The control provides feedback to the AHU that cool air is required. ii. If the AHU is in cooling mode, the VVT airflow setpoint is increased to the maximum cooling CFM setpoint. iii. Feedback is provided to the AHU that cool air is required. b. When the temperature of the zone lowers below the heating setpoint i. The control provides feedback to the AHU that heating is required. 10

18 ii. If the AHU is in heating mode, the VVT airflow setpoint is increased to the maximum heating CFM setpoint. iii. Feedback is provided to the AHU that warm air is required. c. When zone temperature is between the heating and cooling setpoint, the VVT airflow setpoint is set to the minimum occupied airflow setpoint. 2. The airflow damper is modulated to maintain the current airflow setpoint a. If the current airflow is below setpoint, the damper is modulated open b. If the current airflow is above setpoint, the damper is modulated closed Figure 1 VVT Control Block Diagram 11

19 CHAPTER III PREVIOUS ATTEMPTS The initial attempt for this thesis involved Fault Detection on a Fan Powered Variable Air Volume (FPVAV) controller. The goal was to use Fuzzy Logic to predict the discharge air temperature of the controller give a set of conditions. The predicted discharge air temperature would be used as a setpoint to determine if the FPVAV controller was in a fault condition. During this research the following difficulties were encountered: 1. The temperature rise of the air across a given hot water coil in each FPVAV was often significantly different from other controllers during similar conditions. The observed temperature rise depended on several factors, some of which were: a. the position of the hot water coil control valve b. the temperature of the plenum air c. the temperature of the air handler supply air d. the position of the damper regulating the air handler supply air 2. To mitigate the FPVAV variances, a minimum temperature rise of 20 F was assumed. However, even with the assumption of 20 F no consistent relation between the discharge air temperature and the position of the hot water valve could be determined with the information present in the control module. The Hot Water Supply Temperature and Air Handler Supply Air Temperature were then used as an additional facet in the Fuzzy Logic. 3. The amount and quality of data was low due to the use of stored trends in a database. These trends were stored in 10 minute intervals without any statistical process methods to store the state of the controller between data points. To 12

20 4. account for the state of the controller the exponentially weighted moving average (EWMA) was used. 5. Gaps occurred in the data when the trend information was not received by the database server. Since several trend points were used for each record, a gap in any one point would cause inaccuracies. To account for this condition, the performance index calculations were moved to the control module and applied to an EWMA calculation. 6. The control lacked a discharge air temperature setpoint, which precluded the ability to use a performance index effectively. Determination of the controller state was significantly more difficult without a reference with which to compare the actual data. Due to these difficulties, the original model was discarded in favor of the model presented in chapter four. Also, fuzzy inference engine was discarded in favor of the JESS inference engine combined with fuzzy sets. 13

21 CHAPTER IV SELECTION OF FAULTS Many different types of faults are considered for the VVT control (IEA Annex 25, 1996) (Schein & Bushby, A Hierarchical Rule-Based Fault Detection and Diagnostic Method for HVAC Systems, 2006). These faults can be caused by, but not limited to, a failure with a unit s sensor, faulted damper actuator, a breach in the HVAC duct, loss of electrical power, or an incorrect or inefficient sequence of operation. A list of potential symptoms for select VVT faults is shown in Table 1. For each fault, each possible indication is shown by a mark in the appropriate column. The difficulty in fault diagnosis for the VVT system is shown when a comparison is made between faults with common symptoms. Here, a damper that is mechanically stuck in position is indiscernible from a failed damper actuator, improper sequence of operation, or software error. In addition, an AHU Supply Air Static Pressure Too Low would have identical indications as a damper stuck in the closed position or a damper actuator failed closed. It is immediately clear from this list that many of these faults will be classified into the same category based on the similarity of the symptoms each of these faults will display. Since many of the faults have similar symptoms, a more general approach to fault detection is taken. Based on the system diagram for a VVT controller (figure 1) performance index data is analyzed for fault conditions in the temperature and flow control systems. Each controller in a VVT system is processed for sensor faults, flow control faults, and temperature control faults. Once each of the controllers is processed, the all of the VVT controllers are 14

22 evaluated for system level faults. If a system level fault is detected any temperature or flow control faults are muted until the system level fault is cleared. Potentially redundant alarms are prevented with this method, and any other actual alarms are most likely ignored by the maintenance personnel until the larger faults are repaired (Schein & Bushby, A Hierarchical Rule- Based Fault Detection and Diagnostic Method for HVAC Systems, 2006). Table 1 Potential Symptoms of Select VVT Failures Fault Damper Stuck or Failed Damper Actuator Stuck or Failed Complete Failure of Temperature Sensor Improper Sequence of Operation Poor Control Tuning Software Error AHU Supply Air Static Pressure Too Low AHU Supply Air Static Pressure Too High AHU Supply Air Too Warm AHU Supply Air Too Cold Temperature Below Setpoint Temperature Above Setpoint Airflow Below Setpoint Airflow Above Setpoint X X X X X X X X X X Unstable Airflow Alarm X X X X X X X X X X X X X X X X X 15

23 CHAPTER V THE FAULT DETECTION SYSTEM The fault detection system used in this report is comprised of four systems (figure 2): 1. A performance index calculation 2. Exponentially Weighted Moving Average Calculation 3. Maintenance of Equipment Status using JavaBeans 4. Jess Inference Engine The performance index is calculated within the control module to take advantage of the continuous sensor information available without the reliance on the database management system, network architecture, or any one of a number of conditions that could prevent the sensor data from reaching the database. By using the control module, the calculation is performed in real-time with existing data instead of relying on the interpolation of information from a database table. This allows the observance of time to be accounted for in the control module and supports a frame-based approach. Process error is used as the performance index for the temperature and flow systems as a simple means to measure the performance of the system control (Seem, House, & Monroe, 2000). The process error is calculated in three steps: 1. Calculation deviation from setpoint 2. Converting the calculated deviation into a normalized error 3. An exponentially weighted moving average is calculated using the normalized error 16

24 Figure 2 Diagram of the Fault Detection System For the temperature system, the control error is calculated using the current temperature and the high and low temperature setpoints. When the temperature is between the setpoints, there is no deviation and the result is zero. Otherwise, the calculated deviation is the difference between the temperature and the exceeded setpoint (equations 1-4). The deviation is separated by which setpoint is exceeded. An increase in the low temperature deviation is seen when the temperature lowers below the low setpoint while the temperature high deviation remains at zero, and an increase in the high temperature deviation is seen when the temperature increases above the high setpoint while the low temperature deviation remains at zero. D TL = 0, if Low Setpoint < Temperature (Equation 1) D TL = Low Setpoint Temperature, if Temperature < Low Setpoint (Equation 2) D TH = 0, if Temperature > High Setpoint (Equation 3) D TH = Temperature High Setpoint, if Temperature > High Setpoint (Equation 4) Where, D TH = Temperature High Deviation D TL = Temperature Low Deviation The airflow setpoint for individual zones may vary due to the size of the room and the mode the VVT control. The actual airflow setpoint may also dependent on the current heating and cooling control signals within the controller. The variable airflow setpoint is accounted for by using the current airflow and airflow setpoint to calculate a percentage of setpoint flow. Due to sensor inaccuracies, any flow setpoint less than 100 CFM will result in an error calculation of 17

25 zero. The resulting percentage is used against a 100% setpoint to calculate high and low flow errors (equations 5-9) Where, ( FlowSetpoint ActualFlow) t 100 FlowSetpoint FlowPercen (Equation 5) D 0, if Actual Flow > Flow Setpoint (Equation 6) FL D FL 100 FlowPercen t, if Actual Flow < Flow Setpoint (Equation 7) D 0, if Actual Flow < Flow Setpoint (Equation 8) FH D FH FlowPercen t 100, if Actual Flow > Flow Setpoint (Equation 9) D FH = High Flow Deviation D FL = Low Flow Deviation Each of the temperature and flow deviations are normalized over a range of zero to 1000 based on an allowable deviation from setpoint before the control system is determined to be in a fault condition (equation 10). For temperature control, a scaling factor if 4 is used and is based on the temperature setpoint programmed into the controller to indicate a fault condition (figure 3). A temperature deviation reading equal to or greater than 4 F is associated with an error level of 1000 and is used to indicate a fault condition in the temperature control system. For flow control, a 50% (40% + 10% allowable error) is used as the scaling factor. The low setpoint for the flow control error is based on the minimum required flow deviation required to trigger a control action by the controller at 100 CFM. The high setpoint for the flow error is based on providing a large error range (40%) in addition to the acceptable before a particular flow control error is considered in a fault condition. An error greater than 50% is associated with an error level of 1000 and indicates an airflow control fault condition (figure 4). 18

26 D E 1000 (Equation 10) K S Where, E = Error Level (0 to 1000) D = Deviation (High Temperature, Low Temperature, High Flow, or Low Flow) K S = Scaling Factor (4 F for Temperature, 50% for flow) Figure 3 Temperature Error as Room Temperature Exceeds Setpoint Figure 4 Airflow Error as Actual Airflow Exceeds Setpoint 19

27 Time is integrated into the error level through the use of an exponentially weighted moving average (equation 11) (Ryan, 2000). To prevent misdiagnosis of a fault due to a transient condition, a steady state condition must be reached before fault detection can occur. The EWMA calculation is considered steady state when the current EWMA value is within 5% of the current result for the associated performance index calculation. After the EWMA error value has reached steady state, a 3-hour delay is added to prevent system fluctuations or transient conditions from causing false positives. The duration of the steady-state time delay was chosen to provide sufficient time to prevent a system transient or temporary condition from being detected as a fault condition. Three hours is chosen as an initial starting point to be refined after further experimentation. The EWMA error steady state indicator and EWMA error level are sent to the database at one minute intervals for the High Temperature Error, Low Temperature Error, High Flow Error, and Low Flow error. These readings are transferred to the CSV file in addition to the normal sensor and control readings from the VVT controller. EWMA o = (λ PI) + (1 λ) EWMA i (Equation 11) Where, EWMA o = Final EWMA EWMA i = Initial EWMA Λ = Smoothing Constant PI = Current result of the performance index calculation To form a data frame, data from the VVT controller and the result of each of the four performance indexes and steady state calculations are grouped as contiguous records in a CSV file and is used as input to the fault detection application. The data that is contained by each frame is: 20

28 1. Control Module Identifier 2. Timestamp 3. AHU Supply Air Temperature (SAT) 4. AHU Supply Air Static Pressure (SP) 5. AHU Supply Air Static Pressure Setpoint (SPSP) 6. Supply Fan Status (SFS) 7. Zone Temperature (ZONE) 8. Low Temperature Setpoint (HTSP) 9. High Temperature Setpoint (CLSP) 10. Actual Airflow (FLOW) 11. Airflow Setpoint (FLOW SP) 12. Damper Position (DAMPER) 13. Maximum Cooling Airflow Setpoint (MCAS) 14. Minimum Occupied Airflow Setpoint (MOAS) 15. High Zone Temperature Error Steady State (HZTE SS) 16. High Zone Temperature Error (HZTE) 17. Low Zone Temperature Error Steady State (LZTE SS) 18. Low Zone Temperature Error (LZTE) 19. High Airflow Error Steady State (HFE SS) 20. High Airflow Error (HFE) 21. Low Airflow Error Steady State (LFE SS) 22. Low Airflow Error (LFE) As records are collected, they are sorted into a CSV file by timestamp and control module identifier number. The data organization that is produced once all the records are collected contains blocks of control module frames that occur at the same timestamp. Successive frame blocks move forward in time as they are read into the fault detection application (figure 5). 21

29 Figure 5 CSV File Architecture All of the frames that occur at the same timestamp are read into the Fault Detection application as successive blocks of data. With the exception of the index and timestamp, a single dimensional array is created for each of the 20 remaining data fields. Each controller is assigned an index value such that the corresponding index in each array corresponds to the current data from that controller. The timestamp is excluded since all the data read in the current block occurs at the same time, and the controller index is used the array index and therefore does not require its own array. Data is read from the CSV file when the read method of the status object is called from the main processing loop in the JESS fault detection program. The JESS inference engine is used by the Fault Detection application to determine if a fault exists in a controller and if multiple controller faults constitute a system fault (figure 6). Controller data is loaded into the JESS knowledge base through the use of dynamic shadow facts, which are JavaBeans with additional code to automatically update the JESS inference engine knowledge base when the key value changes. A group of shadow facts are generated for each of the remaining 20 data points, and each controller is assigned its own group. Each group is identified by an index number that corresponds to an array index in the status object. During each iteration of the main processing loop, the status object is called to read in the next block of control module frames and store the new data in the single-dimensional arrays. The new data is 22

30 read by the dynamic shadow facts read and, if value has changed, the knowledge base is updated. The inference engine is then run on the new data and the results can be analyzed. Figure 6 Fault Detection Model The four error values are fuzzified by the dynamic shadow facts as they are read into the JESS knowledge base. Rather than determining whether a value in contained in a set, the degree of membership a value has with a set is measured. The resulting degree of membership is usually a value between 0 and 1. In this report, the error value is subdivided into five regions by triangular membership functions. 1. Normal <= < Low < < Medium < < High < < Failed The membership functions for each of the five fuzzy terms are shown in figure 7. As the error value is increased from zero to 1000, the resulting membership to each of the five fuzzy sets 23

31 changes accordingly. The error value is converted into a fuzzy value using the membership function of the corresponding set. Figure 7 Fuzzy Membership Functions The fault detection application is divided into two objects: the VVT Control object (Appendix A) and the JESS Inference Engine (Appendix B). The fault detection process is started when the JESS application is executed. A VVT Control object is created by the JESS application. While the VVT Control object is constructed, the number of VVT controllers is counted. Arrays for each of the data columns are initialized in the VVT Controller, and JavaBeans are initialized with pointers to the VVT Control object and the controller index the JavaBean represents. With the index, the JavaBean can access the correct information in the VVT Control object and fire update events to trigger JESS to update its working memory if the key value has changed. Once the JavaBeans are initialized, the rules are declared and control processed to the main processing loop. The Main Processing Loop is shown in figure 8. Since JESS does not support a FOR loop structures the WHILE loop is used to cycle through each frame of data from the input file. Once the data is read and the appropriate data array positions updated, the setdatarow thread relinquishes control for a time. During this pause, the JavaBean values are updated and, if those values have changed, property change notifications are sent to the JESS engine. Without this pause the contents of the working memory will still be in the process of being updated when the rules are applied. During this condition, indeterminate results are produced. Once the pause has expired, the rules are applied on the facts in working memory by the JESS run command. 24

32 (bind?count 0) (while (>?filesize?count) (bind?count (+?count 1)) (call?*vvt_control* setrowdata) (run) ) Figure 8 Main Processing Loop As each frame of data is processed, the facts in the working memory are applied to the rules in five phases. Each phase is separated by a salience declared in each rule. The rules are then prioritized by the agenda to apply those with a higher salience first. During the fault detection process, multiple faults can be triggered by a single failure. For example, a temperature control fault may be generated due to a flow control fault in the VVT control. Due to the subsequence excessive or insufficient airflow from the AHU, high or low temperature control faults may be detected and is considered a false positive. To prevent these cascading faults from occurring, the fault detection process is divided into five phases in the inference engine agenda through the use of salience. The first phase is comprised of individual sensor faults for temperature and flow sensors. Actual zone level faults involving flow control us separated into the second phase, and zone temperature control in to the third phase. System level faults are detected in the fourth phase. Finally, a fifth phase is used for reporting the results of the FDD inference logic. Each phase is separated through an assigned rule salience, which causes rules with a higher assigned salience to fire first. A default salience of 0 is assigned to all rules that do not have such a declaration. The assigned salience for each phase is shown in table 2. 25

33 Table 2 Jess Rule Salience Phase Detection Salience One Sensor Faults 500 Two Flow Control Faults 400 Three Temperature Faults 300 Four System Faults 200 Five Reporting 100 During the first phase, sensor failures for the zone temperature and VVT flow are detected. Detection of sensor failure is necessary to prevent misdiagnosing a temperature or flow control fault that is caused by a sensor or actuator malfunction. For the zone temperature sensor, sensor readings above 150 F and below -50 F are considered high and low sensor faults, respectively. In addition, a sensor reading that is at the low end of the programmed sensor range is considered a sensor malfunction fault. For this report, the low end sensor range is assigned a temperature of 45 F. Faults are summarized by table 3. During phase two, flow faults are detected. These faults are caused by the actual airflow being sustained either higher or lower than setpoint long enough for the EWMA to have reached a steady state condition and the steady state timer to have timed out. In application, this condition can be caused by flow system errors such as flow sensor drifting, damper and damper actuator failures, ductwork failures, balance damper misalignments, air handler supply fan faults, etc. The flow error is converted to a fuzzy value and used in the inference logic to indicate that a fault exists during this stage. During the reporting stage, the actual value is defuzzified to indicate the severity of the fault. Temperature control faults are detected during phase three. While a temperature error can be caused by a flow error, it can also be caused by many other factors such as thermostat placement, building envelope problems, air handler temperature control issues, over occupancy, etc. Therefore, it is important for the flow error to be eliminated as a potential cause before 26

34 evaluating the temperature error. In a similar fashion to the flow fault, the temperature error is converted to a fuzzy value and used in the inference logic to indicate that a temperature fault exists. During the reporting stage, the actual value is defuzzified to indicate the severity of the fault. Table 3 Sensor Faults Fault Conditions Method of Initiation Temperature Sensor Failed Low Temperature Sensor Failed High Temperature Sensor Misconfigured Temperature less than -55 F Temperature greater than 150 F Temperature sensor reads 45 F Sensor locked at -55 F Sensor locked at 155 F Sensor locked to 45 F Once flow and temperature errors are detected, the potential for a system error is evaluated during phase four. All the VVT controls in a system are affected by a fault at the air handler. For example, if the supply fan is unable to be increased to the static air pressure to setpoint, or the supply air temperature to be increased to setpoint, then the VVT controllers will be unable to provide the required airflow or heating capacity to the areas they serve. Finally, the errors are diagnosed during phase five. The fuzzy values of the flow and temperature error signals are used to signify the severity of the fault. In addition, the phase hierarchy is used to filter faults that could be the result of other faults that have occurred. Flow control faults are prevented by flow sensor faults. Temperature control faults are prevented by temperature sensor faults from phase one and flow control faults from phase two. Both temperature and flow faults for all VVT controls are prevented if a system fault is diagnosed. Testing of the fault detection engine is accomplished in two phases. During the first phase, faults are induced into controllers and the resulting data is used to test that the inference engine will detect those faults. Actual controller data is used during the second phase to evaluate the performance of the inference engine on real life data. 27

35 CHAPTER VI PHASE ONE TEST RESULTS Twenty-one cases for fault detection are considered during phase 1. These cases are listed: 1. Temperature Sensor Failed Low 2. Temperature Sensor Failed High 3. Temperature Sensor Misconfigured 4. Low Temperature Control Fault (Low, Medium, High, Failed) 5. High Temperature Control Fault (Low, Medium, High, Failed) 6. High Flow Control Fault (Low, Medium, High, Failed) 7. Low Flow Control Fault (Low, Medium, High, Failed) 8. System Temperature Control Fault 9. System Flow Control Fault A test is considered successful if the appropriate test case is chosen by the inference engine no sooner than 3 hours after the fault initiation and no later than 4.5 hours. 3 hours is chosen as the low limit due to the possibility that the EWMA could arrive at a steady state value due to a coincidental shift in the control deviation. 4.5 hours is chosen as the upper limit due to design delay in the EWMA reaching steady state, subsequent 3 hour time delay, and an additional 10% of acceptable error. Results for each case are summarized in table 4. 28

36 High Airflow Faults Low Airflow Faults High Temperature Faults Low Temperature Faults Sensor Faults Table 4 Phase 1 Test Results Symptom Fault Detection Time Detected Time Clear Temperature Sensor reads - 55 F Temperature Sensor reads 150 F Temperature Sensor reads 45 F Temperature 1 F below setpoint Temperature 2 F below setpoint Temperature 3 F below setpoint Temperature 4 F below setpoint Temperature 1 F above setpoint Temperature 2 F above setpoint Temperature 3 F above setpoint Temperature 4 F above setpoint Flow sensor reads 20% below setpoint Flow sensor reads 30% below setpoint Flow sensor reads 40% below setpoint Flow sensor reads 50% below setpoint Flow sensor reads 20% above setpoint Flow Sensor reads 30% above setpoint Flow sensor reads 40% above setpoint Temperature Sensor Failed Low Temperature Sensor Failed High Temperature Sensor Misconfigured Low Temperature Control Error (Low) Low Temperature Control Error (Medium) Low Temperature Control Error (High) Low Temperature Control Error (Failed) High Temperature Control Error (Low) High Temperature Control Error (Medium) High Temperature Control Error (High) High Temperature Control Error (Failed) Low Airflow Control Error (Low) Low Airflow Control Error (Medium) Low Airflow Control Error (High) Low Airflow Control Error (Failed) High Airflow Control Error (Low) High Airflow Control Error (Medium) High Airflow Control Error (High) 3 Hours 59 Minutes 3 Hours 59 Minutes 3 Hours 59 Minutes 3 Hours 59 Minutes 3 Hours 59 Minutes 4 Hours 57 Minutes 3 Hours 27 Minutes 4 Hours 1 Minute 3 Hours 29 Minutes 3 Hours 29 Minutes 3 Hours 29 Minutes 3 Hours 59 Minutes 3 Hours 59 Minutes 3 Hours 29 Minutes 3 Hours 29 Minutes 3 Hours 59 Minutes 3 Hours 59 Minutes 3 Hours 29 Minutes 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 6 Hours 29

37 System Faults Flow sensor reads 50% above setpoint Three (or more) VVT Controls report temperature faults Three (or more) VVT Controls report airflow faults High Airflow Control Error (Failed) Temperature System Fault Airflow System Fault 3 Hours 29 Minutes N/A N/A 6 Hours N/A N/A The results for the zone high temperature error calculation during a high temperature sensor failure are shown in figure 9. This fault is implemented by locking the zone temperature reading into the fault detection logic at 150 F as the other parameters are allowed to remain at their normal values. The fault is initiated at hour one as shown by the zone temperature sensor reading immediately increasing to the error value. During the second hour, the high zone temperature error exponentially decays to the final error value of Once there, in internal timer delays the steady state indication by three hours. Four hours after the fault is initiated, the steady state indicator for the high zone temperature error is set and held until the fault clears. This condition is sensed by the rule based inference engine during phase 1 through the use of four conditions: 1. Actual Zone Temperature the fault is classified as a zone sensor failure since the actual zone temperature is greater than 120 F 2. High Zone Temperature Error the zone error is translated to a fuzzy value of failed to show the error level is sufficient to trigger a sensor fault 3. High Zone Error Steady State the zone error is held for a sufficient time period to indicate a genuine fault 4. Status Word if a sensor fault has been detected previously, do not repeat the alarm The four conditions needed to detect a temperature sensor failure are shown in the rule s LHS. The index of the control in question is referenced between each pattern to force the rule to only look at attributes for the same control. When the conditions in the four patterns are satisfied, 30

38 the rule fires and executes its RHS. Here, a notification is sent to the console window and the zone sensor failed JavaBean is set to TRUE for this control. Figure 9 Temperature Sensor Failed High Results Of the four conditions needed to detect that a temperature sensor has failed, only three of those conditions are checked to reset the senor failed JavaBean. First, the fuzzy value that is used to detect that the fault level indicates a sensor failure must no longer be in the failed fuzzy value s range. Second, the zone temperature is read at a value below 120 F. Finally, the sensor must be in a failed condition. Repeated detection of cleared alarms is prevented by including the sensor failed JavaBean pattern, and therefore this rule is fired only when the sensor is in a failed state. The high zone temperature error steady-state condition is not checked for the clear rule since it the check is redundant due to the inclusion of the high zone temperature error fuzzy value condition. When this rule is fired, a notification is sent to the console window and the sensor failed indicator is reset. The results for the zone low temperature error calculation during a low temperature sensor failure are shown in figure 10. This fault was implemented by locking the zone temperature reading to the fault detection logic to -55 F as the other parameters are allowed to 31

39 remain at their normal values. The fault is initiated at hour one as shown by the zone temperature immediately decreasing to the error value. The response of the low zone temperature error and low zone temperature error steady state values is seen to be almost identical to that of the temperature sensor high fault. Figure 10 Temperature Sensor Failed Low Results Values similar to those of the temperature sensor high failure is checked to detect a low temperature sensor failure, and for the same reasons: actual zone temperature, low zone temperature error, low zone temperature steady state, and temperature sensor failed. Due to the similarity with misconfigured sensor fault, an additional pattern is added to the LHS of the rule. This pattern is used to check that the zone temperature is not equal to 45 F, which is used to indicate that the zone temperature sensor is not configured properly and is the value assigned to the low end of the sensors programmed range. The results for the zone low temperature error calculation during a low temperature sensor failure are shown in figure 11. This fault was implemented by locking the zone temperature reading to the fault detection logic to 45 F as the other values are allowed to remain at their normal values. The fault is initiated at hour one as shown by the zone temperature immediately decreasing to the error value. The response of the low zone temperature error and 32

40 low zone temperature error steady state values is seen to be almost identical to that of the temperature sensor low fault. Additional time is required to detect the misaligned temperature sensor due to proximity the failed temperature has with the actual reading. Once a steady state condition is reached and the three-hour wait is elapsed, the steady state flag is set. Unlike the temperature sensor failed low rule, the zone temperature is checked to be 45 F. Once the fault has cleared, the low zone temperature error does not decay to zero as smoothly as the previous two faults due to the proximity of the actual temperature to the heating setpoint used in the error calculation. Figure 11 Temperature Sensor Misconfigured Results The error response to the low zone temperature faults are shown in figure 12. For each of the error levels (-1, -2, -3, and -4 F) the corresponding error trend is shown. The fault is initialed by assigning the temperature at each of the four fault levels, and the low temperature setpoint to 70 F. The error values for the first two faults, -1 and -2 F performed as expected, the -3 F triggered approximately 27 minutes late while the -4 F error triggered 33 minutes early. When these frames are applied to the JESS inference engine, the faults are successfully detected at those timestamps. 33

41 The error response for the high zone temperature faults are shown in figure 13. For each of the error levels (+1, +2, +3, and +4 F) the corresponding error trend is shown. The fault is initiated by assigning the temperature at each of the four fault levels and the high temperature setpoint to 75 F. The error values of the first fault performed as expected, however the remaining three reached their steady-state condition 31 minutes early. When these frames are applied to the JESS inference engine, the faults are successfully detected at those time stamps. The error response for the low airflow control faults are shown in figure 14. For each of the error levels (-20, -30, -40, and -50%) the corresponding error trend is shown. The fault is initiated by assigning the airflow at each of the four fault levels and flow setpoint to 1,000 cfm. The error values of the -20% and -30% faults performed as expected, however the remaining two reached their steady-state condition 31 minutes early. When these frames are applied to the JESS inference engine, the faults are successfully detected at those time stamps. Figure 12 Low Temperature Control Error Trends 34

42 Figure 13 High Temperature Control Error Trends Figure 14 Low Airflow Control Error Trends The error response for the high airflow control faults are shown in figure 15. For each of the error levels (+20, +30, +40, and +50%) the corresponding error trend is shown. The fault is initiated by assigning the airflow at each of the four fault levels and flow setpoint to 1,000 cfm. The error values of the +20% and +30% faults performed as expected, however the remaining two reached their steady-state condition 31 minutes early. When these frames are applied to the JESS inference engine, the faults are successfully detected at those time stamps. The Airflow and Temperature Control faults are tested on a system level my initiating either a temperature or airflow control fault in three VVT controllers in three different frames. In both cases, the first two faults are detected normally, and the system fault is triggered on the third 35

43 detection. Subsequent temperature or airflow control faults are still detected but ignored until the number of total faults in either case is reduced to less than three. Figure 15 High Airflow Control Error Trends 36