dites au niveau des équipements.

Par rapport aux approches de type AFDD existantes, cette nouvelle méthode offre les avantages suivants : 1) La structure modulaire et la méthodologie généralisée permettent à cette méthode d'être appliquée à une grande variété de systèmes CVC et de bâtiments.

2) Cette approche relie les défauts d'équipement aux symptômes de confort du bâtiment perceptibles par les occupants.

3) Le système HVAC est diagnostiqué dans son ensemble au lieu de le faire équipement par équipement.

4) En connectant chaque violation de point de consigne de confort avec les défauts des équipements, et en recherchant les défauts racines pour chaque défaut d'équipement de zone, le nombre total d'alarmes est grandement réduit. 5) Les gestionnaires d'installations peuvent utiliser l'outil de manière interactive, en mettant à jour les données de certains noeuds du réseau bayésien sur la base d'observations terrain.

Résumé

Dans les systèmes de chauffage, de ventilation et de climatisation (CVC, en anglais HVAC pour « Heating, Ventilation and Air Conditioning »), les défauts des équipements et les erreurs de fonctionnement causent des problèmes de confort et un gaspillage d'énergie. Pour aider les gestionnaires d'installations à identifier et à corriger plus efficacement les défauts, il est essentiel de disposer d'un outil de détection et de diagnostic automatique de défauts (AFDD), capable de détecter automatiquement les problèmes de confort et d'énergie et d'en identifier les causes.

Les méthodes AFDD existantes se concentrent principalement sur la détection et le diagnostic de défauts au niveau des équipements. Peu d'attention n'est accordée au diagnostic au niveau du bâtiment global, qui permet une détection plus efficace en s'appuyant sur l'interdépendance entre les équipements tout au long de la chaîne de distribution d'énergie.

Cette thèse propose une nouvelle méthode AFDD pour les bâtiments, basée sur les données d'exploitation collectées par les systèmes de gestion technique du bâtiment (GTB, en anglais BMS pour « Building Management System »). Cette méthode est conçue autour d'un réseau bayésien qui permet de détecter les défauts des équipements HVAC en s'appuyant sur une meilleure décision basée sur la fusion des informations et des données provenant des différents niveaux de composants. Cela permet de réaliser un diagnostic de défaut intégré de la globalité du bâtiment. Une originalité importante de cette contribution porte sur l'exploitation des historiques de fonctionnement et des techniques d'apprentissage pour aider au paramétrage automatique de l'outil de détection.

Notre méthodologie comprend les deux parties suivantes :

1. Une nouvelle manière systématique de transférer des informations de topologie de systèmes de bâtiment et des connaissances d'experts pour la construction modulaire du réseau bayésien.

2. Une nouvelle approche pour intégrer des détections de défaut au niveau des équipements dans un réseau bayésien de diagnostic du bâtiment complet. Nous utilisons une méthode de régression pour les équipements centraux (par exemple, groupe froid, chaudière et central traitement d'air), apprise sur des données de fonctionnement normal collectées lors d'un test de mise en service. Pour les équipements dans les zones d'usage, nous utilisons un modèle probabiliste des corrélations entre données de consigne et de mesure.

Une fois le réseau mis en place et les données -mesures et prédictions -collectées, le réseau est à même de calculer la probabilité de différents défauts dans le système bâtiment complet, et d'en identifier les causes les plus probables.

Nous avons testé ce nouvel outil de diagnostic des défauts sur des données provenant de simulation et de deux bâtiments réels afin de tester les performances en termes de détection. Les résultats montrent que notre approche est capable de gérer facilement un grand nombre d'équipements et d'identifier correctement les causes à partir des données mesurées et pré-This thesis proposes a new building AFDD method based on operation data collected by Building Management Systems (BMS). The method uses Bayesian Network to achieve buildinglevel integrated fault diagnosis and equipment-level data-driven fault detection by information fusion of data collected from different equipment of HVAC systems. An important contribution relates to the use of operating data and learning techniques to automatically tune some parameters of the detection tool.

Our methodology is composed of the following two parts:

1. A new systematic way of transferring building system topology information and expert knowledge to a Bayesian Network.

2. A novel approach for integrating equipment-level fault detection results into a buildinglevel fault diagnosis Bayesian network. We use regression methods for central equipment (e.g. chiller, boiler, and Air Handling Unit), learned from normal operation data collected during a commissioning test. For room equipment, we use probabilistic models of correlations between control and measurement data.

Once the fault diagnosis network is set up and all of the evidence is collected, the network is able to calculate the probability of different faults and identify the most probable root faults.

We implemented the fault diagnostics Bayesian network on one simulation data set and two real building operation data sets to test the performance of the AFDD method. The results show that the method is able to easily handle large numbers of equipment, and correctly identify root causes with given evidence.

Compared to existing AFDD methods, the new method provides the following benefits:

1) The modular structure and generalized methodology allow the method to be applied to wide variety of HVAC systems.

2) The method connects equipment faults to building comfort symptoms perceivable by occupants.

3) The HVAC system is diagnosed as a whole instead of equipment by equipment.

Acknowledgment

I would like to express my deepest appreciation to my supervisors, Sylvain Marié, Patrick Béguery, Simon Thébault, and Stéphane Lecoeuche. Without their guidance, encouragement, and support, I would not have been able to complete the thesis.

My supervisor Professor Stéphane Lecoeuche gave me essential guidance in defining the research scope, consolidating the theoretical foundation, and structuring the thesis manuscript.

My co-supervisor and directors at CSTB provided me excellent research infrastructure, learning opportunities, and group cooperation support. I would like to thank Simon Thébault for his consistent encouragement and support. I also would like to thank Antoine Breitwiller for providing the data pre-processing tool TSAR. Last but not least, I sincerely thank my directors Stéphanie Derouineau and Jean Christophe Visier, and all the colleagues whom I worked with, for providing me such a pleasant working experience at CSTB. My co-supervisors from Schneider Electric consistently supported my research interest and provided data for the tests. Sylvain Marie was deeply involved in the discussion of data modeling and Bayesian networks, which helped me shape the integrated FDD methodology. Patrick Béguery provided me the simulation model of Green O Valley building and helped me collect operation data in this building, which were used to test the developed method. I thank Henri Obara who helped coordinate with the facility managers in Green O Valley building and set up FDD tests with the Air Handling Unit. Thanks to Bartosz Boguslawski and other colleagues at Schneider Electric for the interesting discussions on data modeling and fault detection. I appreciate the feedbacks and comments from my reviewers Dirk Saelens and Marie-Cécile Pera, and other jury members, Philippe Leray, and Véronique Delcroix. Thanks a lot for all the kind and encouraging words as well as inspiring questions.

Words can not express my gratitude to my husband who took over so much work at home to allow me to invest all my time and energy into the research, my parents and parents-in-law for helping take care of my new-born baby in his first year, and my two children for being so lovely and understanding. Without the full-hearted support of my whole family, it would not be possible for me to complete the degree.

Inference results of

Background

Causes of building performance gap

Buildings, industry, and transportation are the three main energy consumers in our society. About 40% of energy is consumed in buildings in the European Union 1 . And within buildings, the Heating, Ventilation and Air-conditioning (HVAC) systems consume the most energy. A lot of effort has been given to reduce energy consumption of HVAC systems in buildings. With the development of the sustainable design concept, high performance building envelopes, and energy efficient heating and cooling systems, today, the building and construction industry has obtained a complete solution to low-energy building design. Various standards and evaluation systems such as RT20122 , EPBD3 , LEED4 defined calculation methods and key performance indicators to encourage green building design.

However, during operation, the actual energy consumption in many buildings are much higher than expected. Sometimes comfort is not guaranteed either. Room temperature setpoints are not maintained, and some rooms are over-heated or over-cooled. The deviation of actual building comfort and energy performance from the designed performance is called building performance gap. What are the problems that cause the building performance gap, and how can we fix them?

To understand this, we need to differentiate between problems occurring in different phases of the building's life time. Figure 1.1 lists major problems that occur in design, construction and operation phase, respectively. To identify and fix the problems, one should follow a backward process, because construction and design issues can only be identified when operation faults are eliminated. Operational problems, as well as some of the construction problems (such as wrong sensor location) can be fixed by maintenance and repair. Most of the construction problems and design problems can only be fixed by system renovation, such as replacing the boiler, reconstructing the piping, and improvement of the building insulation. HVAC equipment and BMS field devices faults: If the HVAC process is not functioning as expected despite the control signal being correct/appropriate, it indicates a fault of the HVAC equipment or the BMS field devices (sensors and actuators). A site visit is necessary to identify the fault, and mechanics will be hired to repair and change damaged parts. BMS field devices sensor faults include sensor drift, loose connection, damage caused by corrosion, or electric short cut. Damper and valve actuator faults include being stuck or leaking, and failure of motors. HVAC equipment faults include short circuit, overload, and mechanical degradation of electrical devices such as fans, pumps, and electric heaters, as well as mechanical issues of heat pumps, boilers, chillers, heat exchangers, such as overpressurization, leakage, or blocking of pipes.

Construction problems

Sometimes, even when all operational faults are eliminated, the building is still not running as expected. Some rooms are constantly too cold or too warm, some Variable Air Volume (VAV) boxes are not getting enough air flow, or the chilled water system is not getting the designed water flow. In such cases, one must further investigate on site to look for construction problems.

Construction problems have the following types. First, installation problems. For example, if a room sensor is installed above a radiator and does not represent the real room temperature, then this room will always be too cold; if the VAV air outlet is covered by the suspended ceiling or some furniture, then the room will never get enough air supply. Second, mechanical components problems. A valve or pipe connector of wrong size or gas in the piping may significantly reduce the water flow and cause the chiller to only give out half of its cooling capacity. Third, building envelope problems. A thermal bridge, un-insulated door, or an opening on the window for running wires can cause significant heat loss such that the room temperature cannot be maintained.

Design problems

Sometimes, after everything has been done to fix operation and construction problems, the building still has difficulty maintaining comfort, or consumes much more energy than expected. In such cases, one should check if there are problems in the building and system design. Such problems could be over-sized or undersized equipment, unbalanced air or water system, inefficient air distribution, etc. Such problems are caused by inaccurate design simulation or design input, such as weather data, building and system properties (heat transfer coefficient, infiltration rate, Coefficient Of Performance (COP) of chiller), or occupancy profile. We henceforth refer to them as inherited building performance gap. These kinds of issues are not easy to prevent in the design phase, and can only be fixed by redesigning and modifying the system after the building is in operation. -Lack of visibility: Facility managers don't have a global view of how well the system performs. As long as the comfort in most rooms are maintained and all equipment are running, no action will be taken. High energy consumption and abnormal operation are not brought to their attention, mostly because there is no benchmark of normal energy consumption or normal operation to compare to. -Labor intensive diagnostics: Typically, diagnostics rely on engineering experience and on-site inspection. In practice, the labor-intensiveness of these tasks is such that they are not routinely performed, and they may never be performed in most buildings.

Periodic re-commissioning would be able to remove these faults and bring the building performance back to the level of the hand over state. In an ideal situation, monitoring-based continuous commissioning helps the building to maintain and even improve the performance during the whole operation phase.

Building management systems provide the technical basis for monitoring-based continuous commissioning. However, only recording operation data is not enough to help facility managers identify and fix faults efficiently. It is essential to have an automatic fault detection and diagnostics (AFDD) tool, which is able to automatically analyze the data, detect comfort and energy issues, and identify the most probable faults that are causing these issues.

We emphasize that the objective of such a tool is to help facility managers and maintenance personal find out faults more efficiently, but not to replace them with a fully automatic system. On-site investigation is still important and necessary to verify and fix faults in buildings.

Motivation

State of the art of commercial fault detection solutions

In most non-residential buildings, fault detection and diagnostics are based on alarms and historical data generated by the HVAC equipment and the BMS. In the last ten years, fault detection and diagnostics platforms started to emerge in the market. In this section, we will describe these three categories of fault detection solutions: HVAC equipment built-in fault detection, building management system alarming, and fault detection and diagnostics platform

HVAC equipment built-in fault detection

A lot of central HVAC equipment has embedded factory-made controllers. These controllers usually have their own fault detection and are able to send alarms to BMS through electrical signals or communication protocols. Since such fault detection solution including the algorithm and all necessary sensors is tailored to the specific equipment and tested in the factory, the results are usually very detailed and precise.

Building management system alarming

Today's building automation systems have the capability to monitor all equipment on a central platform. On this platform people can view real-time values in graphics, change settings (set points, schedules, control parameters), and override commands (boiler, chiller, fan, and pump on-off, valve and damper opening degrees). With the help of the building automation engineering software, system integrator and facility managers can program any alarms for specific applications, including out-of-range alarms and command failure alarms. Simple faults such as pump not running (command failure) or heating coil about to freeze (temperature out of range) can be detected with these alarms. The system also has built-in alarms for lost communication and wiring mistakes of sensors and actuators.

A few examples of mainstream building automation systems are: EcoStruxure™ Building Operation from Schneider Electric (as shown in Figure 1.4) 5 , Desigo™ from Siemens 6 , and WEBs-AX™ from Honeywell 7 .

Fault detection and diagnostics platform

New emerging fault detection platforms integrate with building management system (BMS), energy management system (EMS) and other systems to get operation data, and provide analytics and rule-based fault detection based on these data.

The market leaders include: SkySpark from SkyFoundry 8 and Clockworks from KGS Build-

Illustration and limitations of existing solutions

In order to illustrate the system topology of different fault detection solutions, the HVAC system of an office building is shown in Figure 1.5 as an example. HVAC equipment fault detection, in this example the alarms from the heat pumps, are generated by the equipment embedded controller. Together with sensor, actuator, and meter data, the data generated in the field are collected in BMS, EMS, and other systems such as lighting. The fault detection platform integrates these systems to get data. Based on the data, fault detection is realized by expert rules.

The current system has the following limitations:

1) Alarms and rule-based fault detection logic are highly customized to specific equipment.

An algorithm implemented in one building usually doesn't apply to another building. A general method capable of addressing different systems is missing.

2) Rule-based fault detection methods are mostly focusing on detecting abnormal equipment behavior. However the connection between equipment fault and building comfort issues is usually missing. For example when room set point violation appears, the existing fault detection methods are not able to reveal the root cause.

3) In HVAC systems, the functionality of room devices are dependent on the central equipment. For example, if the boiler or the hot water pump is not working, the associated room radiators don't work as well. The inter-dependency between equipment is usually not considered in existing fault detection methods. Tracing causal relationship between equipment faults remain as a labor intensive manual work.

In practice, tracing root causes involves great amount of manual work and expert knowledge, including sorting big number of alarms, observing data trend log (time series) of specific equipment in specific time period, as well as navigating between associated equipment.

Research questions and scope

In this research, we want to answer the following questions:

1) How can we automatically link comfort violation symptom to the root faults using BMS data? The root faults may be located in other part of the system.

2) How can we automatically identify abnormal behavior of an HVAC equipment from BMS data?

9. http://www.kgsbuildings.com/clockworks 10. https://www.se.com/fr/fr/work/solutions/building-management/ Figure 1.5 -Fault detection system topology and alarms data processing principles Considering the practical condition in buildings, our methods need to fulfill the following requirements:

1) Very easy to adapt to various HVAC system types and typologies.

2) Very flexible with data availability, tolerant to missing data and data error.

Since it is a very challenging and wide topic, we limit our research scope to the followings: 1) Symptoms: We focus on comfort set point violation. We consider temperature as first step, and the method can be extended to include other comfort criteria, such as air quality measured by CO2.

2) Faults: It's most important to identify the fault source equipment and fault categories, in order to help facility managers to set priorities of site investigation and be more efficient in finding the right professionals to fix the issues.

3) Building and HVAC systems: In this study we focus on non-residential buildings with common central HVAC systems. First deployment is based on two real office buildings, which are offered as test buildings by CSTB and Schneider Electric. 4) Data: Since the study is aiming at industry deployment in near future, we mainly consider commonly used sensors and actuators collected by BMS in non-residential buildings, with reasonable time interval of data trend logs.

Contribution

To overcome the above mentioned limitations of current systems, we propose a new automatic fault detection solution. The structure of the overall solution is illustrated in Figure 1.6. Unlike existing AFDD systems such as the one in Figure 1.5, the new method considers equipment faults inter-dependency, and is able to automatically reveal root faults of comfort symptoms.

Our methodology is composed of the following two parts:

1. A new systematical way of transferring building system topology information and expert knowledge to Bayesian Network. Since building HVAC systems have a lot of variations, it is highly important to define a modular structure of the Bayesian network, which applies to different systems. We started from a specific HVAC sub-system, then developed a generic model for HVAC sub-systems, and extend it to various applications. At last an example of whole building fault diagnosis Bayesian Network is given.

A novel approach of integrating equipment level fault detection results into the building level fault diagnosis Bayesian network.

Rule based fault detection results are integrated as hard evidence, and process history based fault detection results are integrated as virtual evidence. The selection of process history based fault detection methods highly depends on the characteristics of the data. In practice building operation data are usually collected without being labeled as normal operation or fault. We chose to use regression method for central equipment (e.g. chiller, boiler, and AHU) with normal operation data being collected in a commissioning test. For room equipment, it's not easy to run commissioning test because of the large number of rooms in a building. We chose to use probabilistic model of time series merits of every room equipment. Assuming most of the rooms are normal, the outliers are regarded to be abnormal.

Benefits of the new AFDD method

Comparing to existing AFDD methods, the new method provides the following benefits:

1) The modular structure and generalized methodology allow the method to be applied to wide variety of HVAC systems. High-level expert knowledge is embedded in the modular structure. Effort and knowledge of implementing AFDD is reduced accordingly.

2) The method not only detects equipment faults but also connects equipment faults to building comfort symptoms perceivable by occupants. Root causes of building comfort issues are revealed. It helps facility managers to react to comfort problems much more efficiently.

3) The HVAC system is diagnosed as a whole instead of equipment by equipment. Different possible root causes of room equipment failure are automatically analyzed, and the most probable root fault is identified. The system knowledge required for tracing root fault among different equipment is embedded in the Bayesian network. 4) By connecting comfort set point violation with equipment fault, and tracing root fault of room equipment failure, the total number of alarms is reduced. All set point violations that are caused by one root cause will be notified as only one alarm. All room equipment failure caused by the same central equipment failure will also be notified as only one alarm. Time needed by facility managers to go through alarms is reduced accordingly. 5) Facility managers can use the tool in an interactive way, thanks to the capability to post evidence in the Bayesian network based on field investigation findings. Field check starts with the most probable faults identified by the Bayesian network. If it is not a real fault, after the information being added to the Bayesian network, an updated fault probabilities will be obtained, which help facility managers in further field investigation. This workflow assembles human's experience in fault diagnostics.

Manuscript organization

The rest of the manuscript is organized as follows:

Chapter 2 reviews existing AFDD methods for buildings and HVAC systems, summarizes the limitation, and introduces the Bayesian network and the reason why we select this method.

Chapter 3 describes the methodology. It starts from the principle of Bayesian network, then introduces the method of setting up building fault diagnosis Bayesian network, and finally explains the method of extracting evidence from data.

Test of the method with simulation data is presented in Chapter 4. And the tests with real building operation data is presented in Chapter 5.

Chapter 6 summarizes the contribution of this work and provides research and application perspectives.

Notation

The notation in this thesis is mostly based on The elements of statistical learning [START_REF] Friedman | The elements of statistical learning[END_REF].

We use upper-case letter to denote a random variable. Usually inputs are denoted by X, If X is a vector, its components can be accessed by subscripts X j . A p-dimensional random variable or input variable is written as X = (X 1 , X 2 , ..., X p) T . Quantitative outputs are denoted by Y, and qualitative outputs are denoted by G. We use uppercase letters such as X, Y or G when referring to the generic aspects of a variable. Observed values are written in lowercase; hence the ith observed value of X is written as x i (where x i is again a scalar or vector). All vectors are assumed to be column vectors. A superscript T denotes the transpose of a matrix or vector, so that x T will be a row vector. Uppercase bold letters, such as X, denote matrices. For example, a set of N input observations with p dimensions would be represented by the N × p matrix X. The ith observation is a vector x i = (x i,1 , x i,2 , ..., x i,p ) T .

Chapter 2

State of the art of building AFDD methods

This chapter gives an overview of the research state of the art of building AFDD methods. Existing methods can generally be divided into three main categories (Katipamula and Brambley, 2005a,b); "quantitative model based" methods using physical models, "qualitative model based" methods relying on expert knowledge, and "process history based" methods learning patterns/models from historical data, including statistical models and machine learning. Our new AFDD method include process history based fault detection on equipment-level, and quantitative model based Bayesian network on building-level. Various data and equipment fault detection result are integrated by the Bayesian Network to achieve building-level fault diagnosis and information fusion. In this chapter, an overview and comparison of different AFDD methods is given, followed by a review of the Bayesian Network theory and its application in fault detection and diagnosis.

Overview of automatic fault detection and diagnosis methods

Starting from the 1990s, extensive research has been conducted on HVAC Automatic Fault Detection and Diagnostics (AFDD). Here we list a few key players: (1) the International Energy Agency (IEA), (2) the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), and (3) California Energy Commission.

-IEA commissioned several collaborative research projects on HVAC&R fault detection and commissioning. Annex 25 (Hyvärinen and International Energy Agency, 1996) identified common faults for various types of HVAC&R systems, and investigated a wide variety of detection and diagnosis methods. Annex 34 [START_REF] Dexter | Demonstrating automated faults detection and diagnosis methods in real buildings[END_REF] summarized 30 AFDD demonstration projects in real buildings from 12 countries. Annex 40 [START_REF] Visier | Commissioning tools for improved building energy performance[END_REF] and Annex 47 [START_REF] Legris | Annex 47 Report 1: Commissioning overview[END_REF] focused on commissioning tools for improved energy performance, and for existing and low energy buildings. -ASHRAE sponsored several research projects on AFDD. RP-1043, RP-1275, and RP-1486 provided an AFDD evaluation tool for chillers, and tested several AFDD solutions. RP-1312 provided an AFDD evaluation tool for Air Handling Unit (AHU) including measurement data and simulation results of normal and faulty operations. RP-1020 described the AFDD demonstration in a real building. -California energy commission funded many AFDD projects including FDD for rooftop air conditioners [START_REF] Davis | Final Report Compilation for Fault Detection and Diagnostics for Rooftop Air Conditioners[END_REF], building performance tracking tool [START_REF] Ulickey | Building Performance Tracking in Large Commercial Buildings: Tools and Strategies[END_REF], and AFDD commercialization program [START_REF] Pasternack | 21st Century Instream Flow Assessment Framework for Mountain Streams: Final Project Report[END_REF] Detailed physical models are able to provide accurate prediction of the building performance when they are well formulated. The challenge of this method is the calibration of building model and the significant effort of implementation.

Qualitative model based methods

Qualitative model-based approaches include rule-based and qualitative physics based methods. Rule-based methods are most widely implemented in practice. The method usually composes of a set of if-then rules. They are further divided into three categories: expert systems, first-principles based, limits and alarms.

Expert systems: [START_REF] Katipamula | Automated fault detection and diagnostics for outdoorair ventilation systems and economizers: Methodology and results from field testing[END_REF] developed the Outdoor-Air Economizer (OAE) which monitors the performances of AHUs and detects problems with outside-air control and economizer operation. The expert rules are implemented in a decision tree structure in software. This algorithm is implemented in the AFDD software Clockworks from KBS Buildings [START_REF] Katipamula | Building Diagnostic Market Deployment-Final Report[END_REF].

First-principles based: (Schein and Schein, 2006).

Limits and alarms: This is commonly supported by building management systems. It compares raw measurements to predefined thresholds, to prevent or highlight potentially harmful operations, such as steam boiler pressure over high limit, heating coil leaving air temperature below freezing temperature, etc.

Rule-based methods are easy to understand because the decision process is very close to what the engineers do in practice. However the if-then structure is not flexible to different configurations of the equipment. It could become too complicated when it comes to global system-level. The necessity of tuning thresholds is another barrier of it's application. Unsupervised learning: One has a set of N observations (x 1 , x 2 , ..., x N ) of a random p-vector X having joint density Pr(X). The goal is to directly infer the properties of this probability density without the help of a supervisor. The following methods have been applied to fault detection:

Process history based methods

1) If we have only normal operation data, unsupervised learning methods learn the correlation between variables, and detect outliers in new data (test data). One class support vector machine (SVM) and primary component analysis (PCA) belong to this kind of method.

2) If we have mixed normal and abnormal operation data, unsupervised methods are used to detect different patterns in the data. The algorithms include clustering, association rules, etc.

Then with help of some expert knowledge, the patterns representing faults can be identified.

We selected 16 papers with great diversity for review.

Linear regression

When we have a p-dimensional input variable X = (X 1 , X 2 , ..., X p ) T , and want to predict a real-valued output Y, the linear regression model has the form

f (X) = β 0 + p ∑ i=1 β i X i (2.1)
Typically we have a set of training data (x 1 , y 1 )...(x N , y N ) from which to estimate the parameters β. The most popular estimation method is least squares, in which we pick the coefficients β = (β 0 , β 1 , ..., βp) T to minimize the residual sum of squares ∑(y if (x i )) 2 .

The variables X i can come from different sources: -quantitative inputs; -transformation of quantitative inputs, such as log, square-root or square; -basis expansions, such as X 2 = X 2 1 , X 3 = X 3 1 , leading to polynomial representations; -interactions between variables, for example,

X 3 = X 1 • X 2 .
Y t = q ∑ k=1 α k Y t-k + t (2.2)
where q and α are the auto-regressive order and the auto-regressive coefficient, respectively.

An auto-regressive exogenous (ARX) model includes input variable X and has the form of:

Y t = q ∑ k=1 α k Y t-k + q ∑ k=1 β k X t-k + t (2.3)
An ARX model can be seen as an extension of a linear regression model, which includes past observations of inputs and outputs as features to describe the system dynamics. Other regression methods such as Support Vector Machine (SVM), Decision Tree (DT), and Artificial Neural Network (ANN) can also include past observations to reveal correlations between time steps which describes the system dynamics. The process of integrating past observations into inputs of such a non-time-aware model is known as "sliding window processing".

Wang and Chen, 2016 applied ARX model to VAV system. Faults can be detected when the residuals exceed the threshold. Fault diagnostics were realized based on expert rules which summarize deviation of certain variables caused by each individual fault.

Turner, Staino, and Basu, 2017 applied a recursive method to estimate parameter of an ARX model on-line. During normal system operation, these parameters converge to stable values. Faults can be detected when the model parameters deviate from their converged values. [START_REF] Ajib | Building thermal modeling using a hybrid system approach[END_REF] employed a PieceWise ARX model to simulate building thermal dynamics.

The resulting discrete states of the system are used to identify functioning modes such as window opening.

Principal component analysis

principal component analysis (PCA) is a linear statistical method for dimension reduction. Theoretically, PCA is based on an orthogonal decomposition of the covariance matrix of the process variables. The original variable space X of p dimension is decomposed into two sub-spaces, the principal component subspace of r dimension and the residual subspace of pr dimension.

The PCA-based AFDD method consists of three main steps: 1) distance and threshold model training based on normal operation data, 2) outliers detection, and 3) variables identification for fault isolation. [START_REF] Xiao | An isolation enhanced PCA method with expert-based multivariate decoupling for sensor FDD in air-conditioning systems[END_REF] applied PCA method on AHU. First they use normal operation data to generate the principal component transformation function, and calculate sum of square of the residuals, namely the Q-statistic or squared prediction error (SPE). They then apply this transformation function to new data and calculate the SPE. Finally they compare it with normal operation SPE; a large deviation indicates a fault. Fault isolation is realized by combining residual vector analysis and expert knowledge.

Support vector machine

Support vector machine (SVM) is a nonlinear machine learning method that optimally separate hyperplanes of dataset for classification and regression.

One-class SVM tries to differentiate the fault-free data class from all other possible fault data classes, by learning from fault-free data only. Its basic idea is to find a minimumvolume hypersphere in a high dimensional feature space to enclose most of the fault-free data. Compared with PCA, it has no Gaussian assumption and is effective for nonlinear process modeling (Zhao, Wang, and Xiao, 2013).

Decision tree

Decision tree (DT) is a nonlinear machine learning method that partitions the feature space by iteratively setting decision thresholds on data features. In each leaf of the tree, the prediction is either a constant value (classic Decision Tree) or a model (Model Tree).

Yan et al., 2016 applied decision tree classification method to AHU fault detection. The training data include normal and faulty operation data, with label of normal or specific type of fault. Before training the decision tree model, the transient data were removed, and a residual generated from a regression model is added to the feature space. The strategy is validated using the data from ASHRAE research project 1312 (RP-1312).

Li et al., 2016 developed a tree-structured Fault Dependence Kernel (TFDK) method. As an improvement of ordinary decision tree methods, TFDK encodes tree-structured fault dependence in its feature mapping, and takes regularized misclassification cost as learning objective. Data-preprocessing include wavelet-based de-noising to remove periodical pattern, and Modified Thompson's Tau method to remove abnormal measurement. The strategy is applied to a centrifugal water-cooled chiller following ASHRAE research project 1043 (RP-1043).

Artificial neural network

Artificial neural network (ANN) is a nonlinear machine learning method that composes multiple stages of linear or nonlinear transformation. In recent years, ANN and more particularly 'Deep Learning' has shown powerful capability in solving high dimensional complex problems such as image and speech recognition.

In AFDD of a building system, ANN can be used to build a black-box model based on normal operation data. [START_REF] Du | Fault detection and diagnosis for buildings and HVAC systems using combined neural networks and subtractive clustering analysis[END_REF] proposed a fault detection tool using ANN and clustering analysis. Historical normal operation data are used to train combined neural networks. After applying the neural networks to new test data, faults can be detected by checking when the residuals exceed the threshold. Through subtractive clustering analysis, the different faults can be separated into different clusters, which is generated from historical labeled normal and faulty operation data. Besides the known faults in the library, the new unknown faults can be recognized and complemented into the faults library adaptively.

Auto-encoder is a symmetrical neural network that can learn the features in an unsupervised manner by minimizing reconstruction errors. It tries to learn an approximation in the hidden layer so that the input data can be perfectly reconstructed at the output layer [START_REF] Sun | A sparse auto-encoder-based deep neural network approach for induction motor faults classification[END_REF]. Auto-encoder is a compressed sensing method, its sole goal is to represent the data in a compressed number of descriptors. However these descriptors may then be used as inputs of any one-class or n-class classification model to perform AFDD.

Bayesian networks

A Bayesian network (BN) is a probabilistic graphical model that represents relationships of probabilistic dependence within a group of variables via a directed acyclic graph. In section 2.3 we will give a specific review on Bayesian network for fault detection and diagnosis.

Zhao, Xiao, and Wang, 2013 developed a three-layer BN to diagnose chiller faults, based on intrinsic causal relationships among causal factors in Layer 1, faults in Layer 2, and fault symptoms in Layer 3. The conditional probability between the layers are defined empirically. When certain fault symptoms are observed, the probability of different fault causes are calculated. The event with highest probability is identified as fault cause.

Clustering

Clustering refers to methods of grouping or segmenting a collection of objects into subsets, so that the objects within the same group are more similar to each other than those in different groups. First of all, the similarities or dissimilarities between objects need to be defined.

Based on the similarity or dissimilarity score, different clustering algorithms are available, such as K-means and hierarchical clustering.

Li and Wen, 2014 developed an AHU fault detection strategy based on pattern matching. The method uses two similarity factors, PCA similarity factors and distance similarity factors, to characterize the degree of similarity between historical data window and current snapshot data.

Miller, Nagy, and Schlueter, 2015 developed a day-typing process that uses symbolic aggregate approximation (SAX), motif and discord extraction, and clustering to detect the underlying structure of building performance data. By applying this method on building whole year energy consumption data, discords due to faults, discords due to holiday operations, weekday motifs, and weekend motifs are identified.

Association rules

The goal of association rules is to discover patterns of variables frequently associated together. Usually it deals with categorical and ordinal variables. [START_REF] Yu | A novel methodology for knowledge discovery through mining associations between building operational data[END_REF] applied association rules to the whole year operation data of the air-conditioning system of a commercial building. The measurements are transformed to fuzzy variable such as high and low. Association rules are extracted such as 'The fresh air temperature after the heating coil in the FHU 4 was high'; 'The fresh air temperature after the cooling coil in the FHU 4 was low'; etc. By examine the logic and consistency of these rules, energy saving potential or faulty operation can be identified.

Gray box models

The previously mentioned algorithms all belong to the family of "black-box" methods. When the model features or parameters have no physical significance, these models are referred to as black-box models (Katipamula and Brambley, 2005a).

In a gray-box approach, the functional form of the model is formulated in such a way that the parameter estimates can be traced to actual physical principles that govern the performance of the system being modeled (Katipamula and Brambley, 2005a). Typically, grey-box models are first or second-order differential equations. Bacher P. and Madson H. use graybox model to simulate heat dynamics of buildings. They formulated a set of different models of increasing complexity, with which building characteristics, such as: thermal conductivity, heat capacity of different parts, and window area, are estimated [START_REF] Bacher | Identifying suitable models for the heat dynamics of buildings[END_REF].

Gunay, Shen, and Yang, 2017 developed gray-box models for AHU and VAV, and fit the parameters using the six-month operation data of a commercial building. AHU economizer faults are identified by unreasonable outside air fraction solved by the gray-box model. Parameters of VAV rooms are compared and the inconsistent rooms are identified as potential faulty rooms.

Limitation of existing methods and need of new methods

Lack of building level diagnostics

HVAC equipment in a building are connected to each other along water and air distribution chain. By nature, inter-dependency exist between equipment through the distribution chain.

For example, if a radiator in a room is not working, it may be caused by local faults, as well as faults of the associated boiler and hot water pump. In practice, it is very important to consider these inter-dependencies to diagnose the faults at the building level.

In practice, building-level fault diagnostics mostly rely on expert knowledge and experience in the specific building. Because of the large number of components and their interdependency, one symptom can be caused by many different root faults. Different root faults require different data and methods to be correctly identified. Some can be monitored by specific sensors, while some others require analysis of data trends of multiple variables. All of this makes the diagnosis process very labor intensive and time consuming. Therefore, an automatic building-level fault diagnostics tool is of great need.

However, in the literature, almost no attention is given to building-level fault diagnosis. We only found two interesting studies working in this area. [START_REF] Schein | A Hierarchical Rule-Based Fault Detection and Diagnostic Method for HVAC Systems[END_REF] proposed a hierarchical rule-based method to prioritize duplicated or conflicting alarms. This study takes into account the equipment inter-dependency, and is very easy to be implemented in practice. But it only applies to a specific application, the rule-based structure is not flexible to different building configuration, system topology, and data availability. In addition, the method is purely based on empirical rules, that need to be tuned for each individual building.

Verbert, Babuška, and De Schutter, 2017 proposed a method based on Bayesian network to deal with equipment inter-dependency in HVAC systems. The studied system has a boiler, an AHU, and radiators served by this boiler. The causal relationship between symptoms and root faults are represented by a Bayesian Network. The conditional probabilities between fault nodes and symptom nodes are derived from statistics generated by building simulation. The prior probabilities of faults are empirically set to 0.01. The network is able to calculate the probability of different faults based on the symptoms.

This method highly depends on accurate and extensive building simulation. Therefore it is not very easy to be deployed in practice. In addition, it only applies to a specific system. The method of easy adaptation to other systems is not given.

Choice of Bayesian Network

We chose to use Bayesian networks to represent equipment inter-dependency and the probabilistic relationships between faults and symptoms. The choice is based on the following reasons:

1) Bayes rule is a natural way of describing causal or probabilistic relationship between faults and symptoms. The parameters (conditional and prior probability) have clear statistical meaning, and the capability to output fault probabilities is more informative compared to binary fault detection results (normal or fault).

2) The graphical structure of Bayesian Network is able to mimic the building HVAC system energy chain. If properly designed, the network is easy to modify and extend to adapt to various HVAC system topologies.

3) Bayesian networks are good in dealing with uncertain, incomplete and even conflicting information, which is very common in building systems.

4) Many efficient methods and tools are existing to solve Bayesian Network inference and belief updating problems.

In the following section we will give a specific review on Bayesian networks for fault detection and diagnosis.

Bayesian networks for fault detection and diagnosis

Application of Bayesian networks in fault diagnosis

The application of Bayesian networks for fault diagnosis can be found in medical diagnostics [START_REF] Cruz-Ramírez | Diagnosis of breast cancer using Bayesian networks: A case study[END_REF][START_REF] Seixas | A Bayesian network decision model for supporting the diagnosis of dementia, Alzheimer's disease and mild cognitive impairment[END_REF], engineering systems (Sahin et al., 2007, Cai, Liu, and[START_REF] Cai | A real-time fault diagnosis methodology of complex systems using object-oriented Bayesian networks[END_REF], manufacturing processes [START_REF] Yang | Bayesian Belief Network-based approach for diagnostics and prognostics of semiconductor manufacturing systems[END_REF][START_REF] Wolbrecht | Monitoring and diagnosis of a multistage manufacturing process using Bayesian networks[END_REF][START_REF] Dey | A Bayesian network approach to root cause diagnosis of process variations[END_REF], and many other fields.

Setting up a Bayesian network for fault diagnosis consists of two steps: identify the structure of the network, and define the parameters including prior probabilities and conditional probabilities. The structure and parameters are obtained from expert knowledge, or learned from data.

Data availability may greatly vary according to the context. A complete data-set contains data for all possible combinations of the variables and their states; a data-set is said to be sparse when data for all the possible combinations of the variables and their states are not available; finally, a data-set is said to be incomplete when values of some of the variables are missing [START_REF] Dey | A Bayesian network approach to root cause diagnosis of process variations[END_REF].

From the literature, we see that there are two types of methods. 1) The Bayesian network is learned from data. It is used when data is rich and complete, such as in medical and manufacture domain.

2) The Bayesian network is set up based on expert knowledge. It is used when data is sparse and incomplete, but the causal relationships between faults and symptoms are more or less known.

Medical diagnostics:

HVAC fault diagnosis using Bayes methods

Building operation data is a typical example of incomplete and sparse data. The data is incomplete because the installed sensors are limited, many variables are not measured. For example, room temperatures are dependent on the weather, internal heat gains, infiltration, heating cooling power from room devices, building enclosure heat transfer coefficient, etc. But among all these variables, only a couple of them are measured. Yet the data availability varies largely from site to site. The data is sparse because fault operation happens rarely comparing to normal operation, and in normal operation the control system is designed to ensure stability around setpoints and avoid uncontrolled variability. Even when the fault operation is included in the data-set, very often they are not labeled for specific fault, and therefore are not present at all.

In the HVAC field, most studies on Bayesian networks FDD methods use expert knowledge to set up the network structure.

Najafi et al., 2012 use Bayes' rule to learn the probabilistic relationships between measurements and fault modes of a specific equipment, and use it for fault detection and diagnosis.

In order to learn the conditional probabilities, collection of data for each specific fault mode were collected. The method is applied to the mixing damper and heating coil in AHUs. [START_REF] Zhao | Diagnostic Bayesian networks for diagnosing air handling units faults-Part II: Faults in coils and sensors[END_REF]Zhao, Xiao, and Wang, 2013;[START_REF] Zhao | Diagnostic Bayesian networks for diagnosing air handling units faults-part I: Faults in dampers, fans, filters and sensors[END_REF] extended the use of Bayes' rule to three-layer Bayesian network, by including multiple faults and symptoms in a network to diagnose chiller faults. The intrinsic causal relationships between fault symptoms, faults, and additional information are represented by a three-layer Bayesian network. Different from Najafi's approach, the conditional probabilities are not learned from data, but defined empirically based on expert knowledge. When certain fault symptoms are observed, the probability of different fault causes are calculated. The one with highest probability is identified as fault cause.

Chen et al., 2018 use the similar method as Zhao, and extend the Bayesian network to multiple equipment, namely the chiller and the air handling unit. The prior probabilities and conditional probabilities are empirically set based on expert knowledge.

Limitation of existing application of Bayesian Network

For building-level fault detection and diagnosis, the existing application methods of Bayesian Networks have the following limitations:

1. The Bayesian network structure is set up based on expert knowledge, and only applies to specific applications. No systematic method is given to easily create Bayesian Network models representing the whole building, taken into account the varieties of HVAC systems and building topology.

2. In most studies, the symptom nodes in Bayesian networks are measurable values, such as room temperature, air supply temperature, air pressure. The conditional probabilities between faults and symptom nodes need to be learned from data. If the network is extended to the whole building HVAC system, the learning process including such large number of nodes would required huge training data set (cover all possible combination of nodes states) and become unrealistic to be implemented in practice.

3. In some researches, the conditional probabilities are purely based on empirical estimations. It requires a lot of in-depth expert knowledge and experience with the specific studied system.

As will be explain in the next chapter, our method uses the Bayesian network structure to describe straightforward causal relationships (mostly simple logic) which requires little or no learning. The uncertainties are summed into nodes and represented in the form of virtual evidences. This modular approach is able to reduce the complexity of the learning process.

Chapter 3

Methodology

This chapter starts with a review of Bayesian network theory (section 3.1), then introduces the new Bayesian Network approach for building level integrated fault detection and diagnosis. Our methodology is composed of the following two parts:

1. A new systematical way of transferring building system topology information and expert knowledge to Bayesian Network. (section 3.2)

Building operation data is a typical example of incomplete and sparse data. It is complicated to learn the Bayesian network structure and parameters from data. Therefore, we decide to define the Bayesian diagnosis network structure based on expert knowledge, and minimize the necessity of estimating conditional probabilities.

Since building HVAC systems have a lot of variations, it is highly important to define a modular structure for the Bayesian network, that can be applied to different systems. We start from a specific HVAC sub-system (section 3.2.1), then develop a generic model for HVAC sub-systems (section 3.2.2), and extend it to various applications (section 3.2.3). At last an example of whole building fault diagnosis Bayesian Network is given (section 3.2.4).

The estimation of conditional probabilities is based on quantified expert knowledge, such as life time of the equipment, or simulation of heating and cooling load. In the contract, the building operation data is used to generate evidence for the Bayesian network, as described below.

A novel approach for integrating equipment level fault detection results into the building-level fault diagnosis Bayesian network. (section 3.3)

In the context of building-level fault detection and diagnostics, we developed methods for integrating equipment level fault detection results into the Bayesian network to provide evidences. Rule-based fault detection results are integrated as hard evidence (section 3.3.1), and process history-based fault detection results are integrated as virtual evidence (section 3.3.2).

The selection of process history-based fault detection methods highly depends on the characteristics of the data. In practice building operation data are usually collected without being labeled as normal operation or fault. We choose to use supervised regression method for central equipment (e.g. chiller, boiler, and AHU) with normal operation data being collected in a commissioning test. For room equipment, it is not easy to run commissioning tests because of the large number of rooms in a building. We choose to use probabilistic modeling based on the time series features of every room equipment. Assuming most of the rooms are normal, the outliers are regarded to be abnormal.

Once the fault diagnosis network is set up and evidence is collected, the network is able to calculate the probability of different faults and to identify the most probable root faults.

Bayesian Network Theory

This session introduces the theory foundation of Bayesian Network. The background material for this session are mainly from Introduction to probability [START_REF] Bertsekas | Introduction to probability[END_REF] and Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference [START_REF] Pearl | Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference[END_REF].

Probability

A probabilistic model is a mathematical description of an uncertain situation. Every probabilistic model involves an underlying process, that will produce exactly one out of several possible outcomes. The set of all possible outcomes is called the sample space of this process, and is denoted by Ω. A subset of the sample space is a collection of possible outcomes. The occurring of the possible outcomes within a subset is called an event. For example, tossing a coin is a process with uncertainty. Head and tail are the two possible outcomes which define the sample space. Tossing a coin and getting head as the outcome is called an event. Another example, target shooting is a process with uncertainty. The sample space is composed by continuous outcomes from 0 rings to 10 rings. Target shooting and getting more than 9 rings as outcome is called an event, which correspond to a subset of the sample space.

In the context of probabilistic reasoning, the probability of an event is the measure of belief.

A probability of 1 implies that we are absolutely certain that the event occurs, and a probability of 0 implies the opposite. Beliefs between 0 and 1 indicate how strong we believe the event occurs.

The initial belief about event A is called 'prior probability'. We use P(A) to denote probability of event A. For example, without any information we assume there is half chance of having rain today. The prior probability of rain is 0.5, so P(A) = 0.5. There may be another event B which is related to event A. The relationship is described by 'conditional probability'. We use P(A | B) to denote probability of event A in condition of event B. For example, based on historical data or experience, when it is cloudy, denoted as B, there is 80% of chance that it will rain, so P(A | B) = 0.8. Therefore, if we observe that it is cloudy, our belief about having rain today changes from 0.5 to 0.8. This is called 'posterior probability'.

It is the updated belief about A given the evidence B. Deterministic logic is a special case of conditional probability. If B always causes A, then the conditional probability P(A | B) = 1.

Random variable

A random variable is associated to the outcomes of an uncertain process. For a random variable X, the probabilities of the possible values is captured by the probability mass function (PMF for short), denoted as p X (x). It is the probability of the event {X = x} consisting of all outcomes that give rise to a value of X equal to x:

P X (x) = P({X = x}) (3.1)
For the rain example, let random variable X be whether or not it rains today, it has two possible outcomes: 1 if it rains, 0 if it doesn't rain. The prior probability of raining is 0.5, P X (1) = 0.5. Let random variable Y be whether of not it is cloudy today, 1 for cloudy, and 0 for not cloudy. The conditional probability of raining given being cloudy is 0.8, P X|Y (1 | 1) = 0.8.

Bayesian networks

Bayesian networks are graphical structures used for representing the probabilistic relationships among a large number of variables and for doing probabilistic inference (reasoning) with those variables. It was first developed by Judea Pearl in 1980s [START_REF] Pearl | Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference[END_REF].

Nodes and edges form the structure of a Bayesian network. Each node represents a random variable. In this study we focus on categorical random variables which have several states. Directed edges are added from parent nodes to child nodes, to indicate that the former directly influences the latter. The child node is independent from all other nodes given its parent nodes.

Parameters are given to each node to describe the probabilities. A node without parent nodes has prior probabilities, which indicate the initial belief about the state of the random variable. A child node has conditional probabilities, which quantitatively describe the probabilistic relationship between the node and its parents. It is composed by a table with all the combination of the states of the parent nodes and the corresponding conditional probabilities of the states of the child node.

Example 1. In Amy's garden, there is a 90% chance that the grass gets wet when it rains and the sprinkler is off, P W|R,S (1 | 1, 0) = 0.9. There is a 70% chance that the grass gets wet when it doesn't rain but the sprinkler is on, P W|R,S (1 | 0, 1) = 0.7. If it rains, and at the same time the sprinkler is on, there is a 97% chance that the grass gets wet, P W|R,S (1 | 1, 1) = 0.97. Finally, there is a slight (1 percent) chance that the grass gets wet caused by something other than rain and sprinkler, P W|R,S (1 | 0, 0) = 0.01. We also know that, when it is cloudy, there is a 80% chance that it rains, P R|C (1 | 1) = 0.8. When it's not cloudy, there is only a 10% chance that it rains, P R|C (1 | 0) = 0.1. Finally, based on experience, there is a 40% chance that it is cloudy, P C (1) = 0.4; and a 20% chance that the sprinkler is on, P S (1) = 0.2.

Figure 3.1 -Bayesian network for the 'wet grass' example.

Example 1 is represented by Bayesian network and shown in Figure 3.1. Each of the four random variables, 'Cloudy', 'Rain', 'Sprinkler', and 'Wet grass', is represented by a node.

The arcs indicate the relationships between the nodes. The prior probabilities and conditional probabilities are listed in the tables.

Inference

If the state of a node is observed, it's called evidence. The process of computing the posterior distribution of variables given evidence is called probabilistic inference. The calculation is based on the following rules.

1) Definition of conditional probability:

The conditional probability of an event A, given an event B with P(B) > 0, is defined by

P(A | B) = P(A ∩ B) P(B) (3.2)
2) Definition of independence:

Event A and event B are independent if the occurrence of B does not alter the probability of the occurrence of A, i.e.

P(A | B) = P(A) (3.3)
3) Product rule (chain rule):

For n events A 1 ,...,A n , assuming that all of the conditioning events have positive probability, we have

P(∩ n i=1 A i ) = P(A 1 )P(A 2 | A 1 )P(A 3 | A 1 ∩ A 2 )...P(A n | ∩ n-1 i=1 A i ) (3.4)

4) Total probability theorem:

Let A 1 ,...,A n be disjoint events that form a partition of the sample space (each possible outcome is included in exactly one of the events A 1 ,...,A n ) and assume that P(A i ) > 0, for all i.

Then, for any event B, we have

P(B) = P(A 1 ∩ B) + ... + P(A n ∩ B) (3.5) = P(A 1 )P(B | A 1 ) + ... + P(A n )P(B | A n ) 5) Bayes' rule:
Let A 1 ,...,A n be disjoint events that form a partition of the sample space and assume that P(A i ) > 0, for all i. Then, for any event B such that P(B) > 0, we have

P(A i | B) = P(A i )P(B | A i ) P(B) (3.6) = P(A i )P(B | A i ) P(A 1 )P(B | A 1 ) + ... + P(A n )P(B | A n )
Based on the definition of independence and the product rule, the joint probability distribution of a Bayesian network is given by the production of all the conditional probability between parent nodes and child nodes. For Example 1, we have:

P C,S,R,W = P C P S P R|C P W|S,R (3.7)
Example 1, Question 1: Based on the prior probabilities and conditional probabilities (no evidence), how much is the probability of 'rain' and 'wet grass'? Note: these are so-called 'marginal probabilities' as we take into account all possible values of other variables in the network to compute them. This process is also known as 'marginalization'.

Let

C = { 1, it rains 0, it doesn't rain R = { 1, it is cloudy 0, it is not cloudy S = {
1, the sprinkler is on 0, the sprinkler is off

W = {
1, the grass is wet 0, the grass is not wet

The probability of 'rain' is given by:

P R (1) = P R|C (1 | 1) • P C (1) + P R|C (1 | 0) • P C (0) (3.8) = 0.8 * 0.4 + 0.1 * 0.6 = 0.38
The probability of 'wet grass' is given by:

P W (1) = P W|R,S (1 | 1, 1) • P R,S (1, 1) + P W|R,S (1 | 0, 1) • P R,S (0, 1) (3.9) + P W|R,S (1 | 1, 0) • P R,S (1, 0) + P W|R,S (1 | 0, 0) • P R,S (0, 0) = P W|R,S (1 | 1, 1) • P R (1) • P S (1) + P W|R,S (1 | 0, 1) • P R (0) • P S (1) (3.10) + P W|R,S (1 | 1, 0) • P R (1) • P S (0) + P W|R,S (1 | 0, 0) • P R (0) • P S (0) = 0.97 * 0.38 * 0.2 + 0.7 * 0.62 * 0.2 + 0.9 * 0.38 * 0.8 + 0.01 * 0.62 * 0.8 = 0.439
Example 1, Question 2: Amy left her home in the morning to work in another town. When she came back in the evening, she saw that the grass was wet. (a) How much is the prob-ability that it rained during the day? (b) If we know it was a cloudy day, how much is the probability that it rained? (a) the probability of raining given the wet grass is:

P R|W (1 | 1) = P R,W (1, 1) P W (1) (3.11) = Σ c,s∈0,1 P C,S,R,W (c, s, 1, 1) Σ c,r,s∈0,1 P C,S,R,W (c, s, r, 1) = Σ c,s∈0,1 P C (c)P S (s)P R|C (1|c)P W|S,R (1|s, 1) Σ c,r,s∈0,1 P C (c)P S (s)P R|C (r|c)P W|S,R (1|s, r)
(b) the probability of raining given the wet grass and cloudy day is:

P R|C,W (1 | 1, 1) = P C,R,W (1, 1, 1) P C,W (1, 1) (3.12) = Σ s∈0,1 P C,S,R,W (1, s, 1, 1) Σ r,s∈0,1 P C,S,R,W (1, s, r, 1) = Σ s∈0,1 P C (1)P S (s)P R|C (1|1)P W|S,R (1|s, 1) Σ r,s∈0,1 P C (1)P S (s)P R|C (r|1)P W|S,R (1|s, r)
The inference results are shown in Figure 3.2. Based on the information of wet grass, our belief about raining is 79%. If we also know that it was cloudy, the belief about raining is increased to 96%. As we can see, one advantage of Bayesian network structure is that each node can be set as an evidence or unknown node. It makes the network very flexible regarding data availability. For more complicated Bayesian networks, the algorithms of inference include exact methods such as variable elimination, poly-tree message passing, and approximate methods such as Monte Carlo simulation, belief propagation [START_REF] Barber | Bayesian reasoning and machine learning[END_REF][START_REF] Neapolitan | Learning bayesian networks[END_REF].

Hard evidence and virtual evidence

When we are absolutely sure about the state of the node, we set the probability of this state to one or zero. This is called hard evidence. Sometimes the information we have is not absolutely reliable, or the measurement we observe is subject to uncertainty. In this case we set the states to a probability between zero and one, and call it uncertain evidence.

Mrad et al., 2015 provided a comprehensive review of uncertain evidence and the proposed terminology, definitions and concepts related to the use of uncertain evidence in Bayesian networks.

There are two types of uncertain evidences (Peng, Zhang, and Pan, 2010):

-The first type, called soft evidence, can be interpreted as evidence of uncertainty, and is represented as a probability distribution of one or more variables. This probability does not get updated in the belief updating process. -The second type, called virtual evidence, can be interpreted as evidence with uncertainty, and is represented as a likelihood ratio. It is used when one is uncertain about a claim of a hard evidence. In belief updating the posterior probability is calculated taken into account the likelihood ratio of this node and the states of other nodes in the network.

In our study, we use virtual evidence to integrate individual equipment fault detection results into the diagnosis network. Below is an example of utilizing virtual evidence.

Example 1, Question 3: In the morning of a cloudy day, Amy left her home to work in another town. When she came back in the evening, she saw that the grass was wet. Based on Bayesian inference result (Question 2), she believed that it rained during the day. But her neighbor said it didn't rain. Knowing that her neighbor's words were not absolutely reliable, Amy has to make her own judgment. (a) If there is a 10% chance that it rained but the neighbor didn't notice, how much is the probability that it rained during the day given other evidences? (b) If there is only a 1% chance that it rained but the neighbor didn't notice, how much is the probability that it rained during the day given other evidences?

Figure 3.3 -Inference results of Example 1-2: left (a) virtual evidence 10% rain, 90% no rain; (b) virtual evidence 1% rain, 99% no rain;

The inference results are shown in Figure 3.3. As we can see, if the virtual evidence of no rain is not very strong (90% certainty), based on the other evidences, we still believe that it rained, and the sprinkler was off. If the virtual evidence of no rain is very strong (99% certainty), we start to believe that it didn't rain, and the wet grass was caused by the sprinkler.

HVAC fault diagnosis network

Building HVAC systems consist of various equipment and systems, from room devices to central equipment, from heating and cooling systems to hydraulic and ventilation systems.

In order to have a generic comprehensive building level fault detection and diagnosis solution, we want to find the similarities between different HVAC sub-systems, and create modular models which can be simply assembled together to represent the whole HVAC system.

In this section we start by creating the fault diagnosis Bayesian Network for a room radiator system (section 3.2.1). Then we introduce the general concept model of HVAC sub-systems and the corresponding fault diagnosis Bayesian Network (section 3.2.2), followed by examples of various HVAC sub-systems (section 3.2.3). At last an example of building level fault diagnosis Bayesian Network is given (section 3.2.4).

Room radiator system fault diagnostics

Figure 3.4 illustrates a room radiator system. The radiator valve is regulated by the controller according to the room temperature and the set point. If the room temperature is lower than the set point, the valve opens to give out more heat; if the room temperature is getting higher, the valve closes to give out less heat. The heating power provided by the radiator to the room depends on the valve status, but also on the hot water supplied as input to the radiator. Finally, the amount of heat required by the room is called heating load. The system is represented in a control block flow diagram manner that is easy to understand for building automation engineers and facility managers. The blocks and signals correspond to the elements of the fault diagnostics Bayesian Network that we will introduce later. In the following we will explain the rules for creating the block flow diagram and how it is mapped to a fault diagnostics Bayesian Network.

The whole system is divided into three blocks: Controller, Radiator, and Room. The input and output variables that can be measured in the system are shown as horizontal signals. The property variables, the input variables coming from other systems (the hot water temperature from the boiler and the hot water pressure from the pump) and environment are shown on top of the blocks.

The purpose of the room radiator system is to maintain the room temperature at the set point. The objective of fault diagnostics is to find out the reasons when the room temperature is significantly deviating from the set point. Now we discuss three situations.

1) When the heating load is zero, typically in transition seasons (spring and autumn), no heating power is required to maintain room temperature at the set point. In this situation, the room temperature is always normal, even if there are faults in the controller or the radiator.

2) When the heating load is between zero and the maximum capacity of the radiator, typically in winter, the controller and the radiator both need to work normally to maintain room temperature at the set point. If a) the controller doesn't open the valve when room temperature is low (controller fault), or b) if the radiator does not give any heat (radiator heating process fault), the room temperature can not be maintained at the set point.

3) When the heating load is larger than the maximum capacity of the radiator, the room temperature can not be maintained at the set point no matter the controller and the radiator are working normal or not. It may happen in an under-dimensioned heating system, or caused by damage of building enclosure including window opening.

In summary, the state of the room temperature (normal or low) is related to the state of all three components of the system: the controller, the radiator, and the room, as shown in Finally, the room heating load is given by the disturbances (outdoor air temperature, solar radiation, internal heat, etc.) and the building enclosure characteristics. The probabilistic relationship can be learned from operation data if available, or from heating load calculation results.

Fault diagnostic Bayesian network of a generic HVAC sub-system

In this section, we abstract the system discussed in the last section into a generic concept model, and introduce the corresponding fault diagnostic Bayesian Network for generic HVAC sub-system.

Generic concept model of HVAC sub-systems

The control block flow diagram of a generic HVAC sub-system is shown in Figure 3.7. It is composed of three components: the Controller, the HVAC, and the Recipient System. The on-off controllers refer to the simple switches to turn on the HVAC equipment, such as 1-stage pump, air fan, air-conditioner, boiler, etc. These equipment are not adjustable, and the controllers don't have set point.

An open-loop control does not require feedback of the controlled variable. Usually the control signal changes with a major disturbance of the system, based on expert knowledge and experience. A typical application is the staged boiler control based on outside air temperature.

What is shown in Figure 3.7 is a regulating close-loop controller. The 'Enable' and 'Set point' signals represent the operation requirement of the HVAC sub-system, and provide the basic criteria to evaluate whether the Controlled Variable is normal or abnormal.

b. HVAC

The HVAC element refers to a heating / cooling / ventilator equipment. It is switched on/off, or regulated by the controller to give heating cooling power or ventilation to the building system to maintain the controlled variable (temperature, pressure, humidity, CO2, etc.). The functioning of the HVAC is determined by the HVAC Component Characteristics and the Energy Sources (if available).

c. Recipient System

The Recipient System refers to a room, a ventilation recipient system (air duct), a hot water recipient system (water tank and piping), etc. To maintain the controlled variable, the Recipient System needs power input from the HVAC. The amount of required power is called load, which is given by the Disturbances and the System Characteristics. If the Recipient System is equipped with Supplemental HVAC, such as ventilation to a room radiator system, the state of the Supplemental HVAC may also impact the system load.

Structure of the fault diagnostics Bayesian Network

In the generic concept model Most of the causal or probabilistic relationships are binary logic, which means the conditional probabilities are either 1 or 0. The only conditional probability that needs to be estimated based on expert knowledge is the one of Recipient System node. The structure of the Bayesian network is purposely designed to minimize the necessity of estimating (or learning) and tuning the conditional probabilities. More explanation on parameters is given in the next section.

At the same time, the design of the network structure allows for standardization of each HVAC sub-system, and for easy connection of all HVAC sub-systems in a building. The connections of different systems are built between the Controlled Variable node of the energy sources and the HVAC node of the energy consumers. An example will be given in 3.2.4.

Parameters of the fault diagnostics Bayesian Network a. Conditional probabilities

Now we will explain the causal or probabilistic relationship between the nodes in the fault diagnostics Bayesian Network, and discuss the conditional probabilities.

1) Controlled Variable and parent nodes -When the load of the Recipient System is 'high' (higher than the maximum power output of the HVAC), the controlled variable is abnormal in any case. -When the load of the Recipient System is 'normal' (above zero and smaller than the maximum power output of the HVAC), the controlled variable is only normal when the Controller and the HVAC are both normal. A Controller fault (including disability) or a HVAC failure will all cause controlled variable to be abnormal. -When the load of the Recipient System is 'zero', the controlled variable is normal in any case. It applies to room and air heating cooling systems in transition seasons. Air fans and pumps usually don't have 'zero load' status, since power is always needed to maintain water pressure and air pressure.

The above mentioned logic represented by conditional probability is shown in 3) Recipient System and parent nodes

The system load depends on the disturbances and the system characteristics. In correctly sized HVAC sub-systems, high system load is caused by abnormal System Characteristics in the condition of certain Disturbances. Take room radiator system as an example, Disturbances refer to weather (outside temperature, solar radiation, etc.) and internal heat gains, System Characteristics refer to the building enclosure heat transfer coefficient and heat capacity. If the radiator has the right size, in normal situations, the heat capacity should always be able to cover the system load. High system loads are caused by building enclosure fault, such as open window or damaged insulation, and only appears when the outside temperature is low.

Sometimes the system is served by more than one HVAC equipment for different purposes, such as heating and ventilation. In this case, abnormal Supplemental HVAC has the similar effect as abnormal System Characteristics. For example, rooms equipped with radiators may be served by a central AHU (Air Handling Unit) for ventilation. In normal operation, the supply air temperature is close to the room temperature. If the heating coil in the AHU is not working, causing low supply air temperature, the heating capacity of room radiator may not be enough to maintain room temperature set-point, and the room is in high load state.

The conditional probability table of Recipient System node is case specific. It can be learned from disturbances data and corresponding system load data in normal case and fault case. If operation data is not available, we can build a physical model of the Recipient System and simulate both fault and normal case with different Disturbances and use this data-set to get the conditional probability table. An example of getting conditional probabilities for a room radiator system is given in 3.2.1.

b. Prior probabilities

In the HVAC diagnosis network as shown in Figure 3.8, the nodes without parents are root cause nodes.

Disturbances refer to variables such as outside air temperature, total heating demand from the rooms to the hot water system, etc. The prior probabilities or probability distribution of the disturbance values can be obtained from historical data.

All the root cause nodes such as Controller, Process Characteristics, and System Characteristics faults correspond to the failure of a specific equipment or building component. The prior probability os equipment fault is often related to the aging of the equipment. Exponential density function is a good model for the amount of time until an incident of interest takes place, such as an equipment breaks down [START_REF] Bertsekas | Introduction to probability[END_REF]. We can make use of this model to assign these root nodes with a reasonable prior probability.

Example 2: Let the 'HVAC' refer to a boiler. The expectation of life time is known to be N years. What is the probability of failure after a years of normal operation?

An exponential random variable can be a good model for the amount of time until an incident of interest takes place, such as a message arriving at a computer, some equipment breaking down, a light bulb burning out, an accident occurring, etc. [START_REF] Bertsekas | Introduction to probability[END_REF] Assume that the boiler's life time X is an exponential random variable. Its probability density function is given by:

f X (x) = λe -λx , x ≥ 0 (3.13)
where λ is the parameter of exponential probability distribution, also known as the "failure rate."

The expectation of X, also known as MTBF (Mean Time Before Failure), is given by:

E(X) = 1 λ (3.14) therefore, λ = 1 E(X) = 1 N (3.15)
The probability of working normally after a years of operation since last maintenance is given by:

P(X > a) = ∞ a λe -λx dx = e -λa = e -1 N a (3.16)
The probability of failure after a years of operation is 1 -P(X > x) = 1e -1 N a . The probability of failure increases with years of operation, and gets reset after the equipment is replaced or repaired. Figure 3.9 illustrates the fault probability of two equipment, with 5 years and 10 years life expectation, respectively.

For the equipment or building components without data-sheet, the prior probabilities of fault may be estimated based on experience. The ratio between prior probability of different root faults has impact on the result in the way that, with specific symptom certain root fault is more probable than the others. Finally, if not much experience nor data-sheet is available, we recommend to set all the fault prior probabilities to be the same, e.g. 0.1. The value of this prior probability (either it is 0.1 or 0.05) only has impact on the absolute value of inference results (posterior probabilities of root faults). The ratio of the posterior probabilities between different root faults remain the Figure 3.9 -Fault probability of an equipment increased with years in operation.

same. Since the fault diagnosis process is based on the ranking of the root faults probabilities (as explained in section 4.5), in stead of the absolute value, it doesn't make much difference whether the prior probabilities are set to 0.1 or 0.05, as long as they are all the same. More aspects about setting parameters and possible research topics for the future are discussed in 6.2.3.

Examples of specific HVAC sub-systems

In this section, the generic concept model is applied to specific HVAC sub-systems. The fault diagnostics Bayesian Networks of each specific HVAC sub-system is created. Note that the electricity grid or natural gas system serving as energy source of boiler, pump, chiller, etc, are external to the building and not included in these examples. If required, these external energy sources can be easily integrated into the models.

Figure 3.10 -Concept model of a hot water boiler system Figure 3.10 illustrates a 'Hot Water Boiler' sub-system. The boiler is regulated by the controller to maintain the supply water temperature at the set point. It can be realized by staging switches or a fuel valve. The boiler gives heating power to the hot water system to compensate the hot water heating load which is given by the total heating demand from all served equipment of the system and the tank and piping heat loss. The fault diagnostic Bayesian Network is illustrated in Figure 3.11. Figure 3.12 illustrates a 'Hydraulic' sub-system. The pump is regulated by the controller to maintain the supply water pressure at the set point. It is realized by a Variable Frequency tem, it has on-off controller instead of regulating controller. The air fan is 1-stage and connected to a constant air duct system (no regulating dampers). There is no set point for the air flow, the controller simply switches on the fan when it is enabled and switches off when it is disabled. The ventilation power refers to the combined pressure and flow rate the air fan is able to provide. It is defined by the fan curve (similar as pump curve). If the Duct is blocked or has leakage (Duct Resistance = Abnormal), the fan would not be able to provide enough power to maintain the air pressure and air flow (Duct System = High load). The fault diagnostic Bayesian Network is illustrated in Figure 3.16.

Figure 3.17 -Concept model of a chiller chilled water system Figure 3.18 -Fault diagnosis Bayesian network of a chiller chilled water system Figure 3.17 illustrates a 'Chilled Water Chiller' sub-system. The chiller is regulated by the controller to maintain the chilled water temperature at the set point. It is realized by use of an electrical expansion valve. The chiller gives cooling power to the chilled water system. The cooling function is dependent on the functioning of the compressor, heat exchanger, and expansion valve, as well as the condenser water temperature and water flow. The chilled water cooling load is given by the total cooling demand from all served equipment to the system and tank and piping heat loss. The fault diagnostic Bayesian Network is illustrated in Figure 3.18.

A summary of all the above mentioned specific HVAC sub-systems model together with the generic model is given in Table 3.6. signals, set-points, controlled variable (only for Radiator close loop control), and control commands are available. There is no energy meter, so the outputs of HVAC nodes (Boiler, Pump, Radiator) are not available. These signals are shown as horizontal signals in the block flow diagram. In the Bayesian Network diagram they are integrated to obtain the state of the sub-system components, and therefore are not visible. The nodes whose state can be obtained from data are marked in the Bayesian Network diagram.

Step4. Identify external inputs of the HVAC component of each sub-system, and include them as parent nodes of the HVAC node in the Bayesian Network. In this application, Boiler and Pump do not have any parent node, since they are not split into multiple components and they are not served by any energy source. Radiator has two energy sources. In the Bayesian Network, they are included as two parent nodes of Radiator node. The third parent node is the radiator mechanical function Valve and Heat Exchanger.

Step5. Identify properties and disturbances of the Recipient System component of each sub-system, and include them as parent nodes of the Recipient System node in the Bayesian Network. The selection of system properties and disturbances are based on practical fault diagnostics purpose and data availability.

The final fault diagnostics network concept is illustrated in Figure 3.19. The system topology is shown in the left, the block flow view and Bayesian Network view are shown in the middle and right respectively. The available data are marked in shade in the flow chart. In the Bayesian network, the evidence that can be obtained from data are marked in shade. The method for obtaining evidence from data will be explained in section 3.3.

Parameters Prior probabilities

As explained in section 3.2.2.3, all root fault nodes and condition nodes have prior probabilities. The prior probability of root fault nodes are empirically set as shown in Table 3.7. The prior probability of the condition node 'Outdoor air temperature' is shown in Table 3.8.

Fault

Normal Boiler mechanical function 0.1 0.9 Boiler controller 0.1 0.9 Pump mechanical function 0.1 0.9 Pump controller 0.1 0.9 Radiator valve and heat exchanger 0.1 0.9 Radiator controller 0.1 0.9 Abnormal Normal Tank and piping heat loss 0.1 0.9 Piping resistance 0.1 0.9 Building enclosure 0.1 0.9 Table 3.7 -Prior probabilities of root fault nodes in the room radiator system application Table 3.8 -Prior probabilities of the disturbance node in the room radiator system application

Conditional probabilities

As explained in 3.2.2.3, the conditional probabilities of Controlled Variable nodes and HVAC nodes are generic as given in Table 3.4 andTable 3.5.

The conditional probabilities of System Recipient nodes are case-specific. In this application, they are assumed as shown below in Table 3.9, Table 3.10, and

Evidence and inference results

A big advantage of Bayesian network is it's flexibility in data availability. Any node can receive evidence. The more evidence there is, the more accurate the inference result is. The methods for obtaining evidence from data will be explained in section 3.3. In the following we will manually set the state of certain node as evidence, and analyze the inference result.

Assume that we observe low room temperature in room 1, this is a symptom node of the network. The objective of the inference is to get the probability of all root fault nodes, and find out the most possible one. In Table 3.12, all root fault nodes, intermediate fault nodes, and condition nodes, that are direct or indirect parents of the symptom nodes are listed.

The symptom nodes of the sub-systems which are served by the same energy source (room temperature of other rooms) are also listed. Evidences collected among these nodes takes effect in the inference results. As we can see, with only the 'low temperature' evidence, all possible root faults have similar probabilities. With more and more evidence, the fault is gradually isolated. In the following, we will go through each case individually. Case 1. Single symptom evidence: The room temperature in room 1 is low. With this single evidence, all root faults are probable. The exact probabilities depend on the priors and settings of conditional probabilities. In this example, since we purposely set all prior probabilities and conditional probabilities in the way that all the root faults are equally supported, the inference result shows that all root fault nodes have same probabilities, as shown in Case 3. Adding symptom evidence from other rooms: The hot water system is also serving room2 and room3. We post evidence that the temperature of these two rooms are both normal. Now all faults related to the hot water system become less possible. The inference result of the Bayesian Network is shown in Figure 3.22 Case 5. Adding HVAC fault probability virtual evidence, radiator fails: Based on historical data of room temperature and room heating control signal in room1, using correlation distribution model method (refer to section 3.3), it is locally believed that radiator 01 fails, with likelihood of 80%. It is introduced in the Bayesian Network as virtual evidence. Now the most probable fault is radiator 01 radiator valve and heat exchanger fault. The inference result of the Bayesian Network is shown in Figure 3.24

Obtaining evidence from data

In the last section we discussed how to create a Bayesian network representation of the building HVAC system, and to find out the most probable faults given some evidence. In this section, we will introduce a few methods for obtaining evidence from building operation data.

We have introduced hard evidence and virtual evidence in 3.1.5. If we are sure about the state of a node, we use hard evidence and set the state to 'true' or 'false'. If we are uncertain about the state of a node, we use virtual evidence and set the state to a likelihood ratio between zero and one. In the belief updating process, the probability of the uncertain evidence nodes will get updated considering evidence from other part of the network.

In our fault diagnosis Bayesian network (the generic representation is given in Figure 3.26), we use hard evidence (shown in dark gray) to represent all rule based evidence, such as state of Controlled Variable, Disturbance, and Controller. HVAC state is based on data modeling and is represented as virtual evidence (shown in light gray). This innovative approach makes the Bayesian network more robust and tolerant to inaccurate equipment-level data driven fault detection results. In our study we assume all collected data are accurate. In another word, there is no sensor error. The approach to integrate sensor errors into the Bayesian network is to change hard evidence to virtual evidence, where the uncertainty of data itself is calculated. This part is not covered in our study. This is a potential topic for future work (see section 6.2.2).

Hard evidence

Controlled Variable

The state of Controlled Variable, Normal / Abnormal, is obtained by comparing the controlled variable data (e.g. the actual room temperature) to the set point during enabled time. The enabled time is given by the building operation hours. As discussed in 3.2.2.1, the set points may come from the HMI (Human Machine Interface) or generally defined according to the comfort criteria. In the example given in the following, we choose to use general room set point, 21 • C in heating mode, and 26 • C in cooling mode. For extracting the evidence from data we go through the following steps:

Apply rules:

In occupied time, if the hourly average room temperature is lower than the heating set point minus a tolerance of 0.5 • C, or higher than the cooling set point plus a tolerance of 0.5 • C, the state is 'Abnormal', otherwise it is 'Normal'. In Figure 3.27 the evidence results are shown in the third subplot.

We choose to use default set point 21 • C and 26 • C (with tolerance: 20.5 • C and 26.5 • C), instead of individual set point from each room unit in the room. The advantage is that:

-It gives a more straight forward overview of room comfort in the whole building.

-If the occupants set an unreasonable set point, it will be noticed as an issue.

Disturbances

The state of Disturbances node is the discretization form of continuous observed data. An example is given in section 3.2.1, the state of the disturbance node Weather is obtained from discretization of measured outdoor temperature.

Controller fault detection

For on-off controllers, during enabled time, the controller output is expected to be 'on'. Therefore the output 'on' and 'off' corresponds directly to the status of the controller 'normal' and 'fault'.

For regulating controllers, once enabled, the normal behavior of a controller is to output control signal in the way that the control error (difference between controlled variable and set point) is minimized. In this study we use a rule based controller fault detection method:

The controller status is 'fault' when the controlled variable is out of set point range for a substantially long time, and the controller doesn't give the maximum control signal (corresponding to maximum power output of the HVAC process). An example is given in the following.

Figure 3.29 illustrates heating controlled variable (room temperature), set point, and control command collected in one room of a real office building (Porte-de-Retz, details in 5.2). The room temperature comfort band is marked in green shade, room temperature tolerant band is marked in yellow shade. The unoccupied time (night time) is marked in gray shade.

For extracting the evidence from data we go through the following steps:

1. Sampling: Continuous room temperature, set point, and heating / cooling valve command data (as shown in the first and fourth subplot of Figure 3.29) are sampled to one hour using average filter (as shown in the second and fifth subplot of Figure 3.29).

Apply rules:

In occupied time, if the hourly average room temperature is lower (higher) than the heating (cooling) set point minus (plus) a tolerance of 0.5 • C, and the hourly average heating (cooling) valve control command is lower than the 'max-threshold' (80% in this case), the controller status is 'Fault'. In Figure 3.29 the evidence results are shown in the sixth subplot.

Here the controller fault includes set point error (in this case, set point too low). Heating set point higher than default value 21 • C (as can be seen in the last two and half days) is not seen as an issue, as long as it is not higher than cooling set point 26 • C.

Virtual evidence

In our study, we investigated two fault detection methods for HVAC based on data modeling: 1) regression model prediction for central equipment, 2) correlation distribution model for room equipment. As we discussed in 2.1.3, the selection of methods highly depends on the available data. Our study is primarily aimed at implementation in the near future. Therefore our investigation is based on common available data in building management systems. We have not investigated methods which employ large number of sensors.

1) regression model prediction for central equipment

Regression model prediction method uses normal operation training data sets to learn the behavior of the system, and detection abnormal behavior which drifts away from the data model prediction. We choose to use this method for central equipment fault detection for the following reasons:

-Central equipment such as Air Handling Unit (AHU) often has sufficient sensors for providing data to train a model. -For these equipment, usually a commissioning test is obligatory to prove the functionality. The commissioning test provides the opportunity to collect normal opera-tion data. We didn't investigate classification methods because usually in buildings it is hard to collect abnormal operation data labeled with the fault classes.

2) correlation distribution model for room equipment

For room equipment such as Fan Coil Unit (FCU), we didn't use regression model prediction method. The reasons are the followings:

-Sensor data on room equipment is usually not enough for learning the equipment behavior. The heating and cooling power of an individual room equipment is usually not measured. And if taking room temperature as model output, the modeling system is extended from equipment to the whole room, where more required variables are not measured, such as heat exchange through opened doors and windows, solar heat gain, internal heat gains, etc. We have investigated and compared different regression model methods, such as ARX, Piece-wise ARX, and random forest. The results show that, with limited measurement data as we usually have in BMS, the data modeling accuracy is not good enough for fault detection. -Because of the large number of equipment in a building, it is difficult to run commissioning test for individual equipment and collect normal operation data. In the end we choose to use probabilistic model of time series correlation, for it requires very limited measurement, and is very easy to implement in practice. As will be explained later, the method only gives a very rough estimation of the likelihood of being fault. If condition allows and more measurement data is available, the method can be replaced by other more accurate methods, as long as the method provides fault likelihood to be integrated as virtual evidence in the building-level fault diagnosis Bayesian network.

The two methods are explained in the following section. Use cases with simulation data and real measurement data are given in 4.3, 5.2.3, and 5.3.3, respectively.

Regression model prediction

As shown in 3.7, the output of an HVAC equipment, 'heating / cooling / hydraulic power', is a function of the input 'control command' and 'energy sources'. The function is determined by 'HVAC component characteristics'. We propose to learn a black-box model based on a collection of normal operation data, and detect fault when the real output deviates significantly from the predicted output. In this method there are four key elements: 1) training data, 2) learning algorithm, 3) residual analysis, and 4) relearning procedure.

1)

Training data: Data needs to be collected in normal operation of the HVAC process, meaning that the process characteristics are normal, and the energy sources are normal. The training data should cover a representative range of the inputs, because a normal operation with the inputs out of training data range may be considered as fault. In practice, we suggest to run a commissioning test covering the full range of the control signal, to collect initial training data. During operation the training data is updated by including more and more normal operation data, see 4) relearning procedure.

2) Learning algorithm: Based on the normal operation training data, different data modeling methods can be used to learn the function between the inputs and the output, such as linear regression, SVM regression, and ARX model (a summary is given in 2.1.3). In our study we use random forest regression method. It has good performance in coping with non-linear systems and preventing over-fitting.

Model fitting

Random forest is based on decision tree algorithm. Decision tree algorithm splits the feature space recursively into a set of sub-spaces, and then fits a simple regression model in each subspace. The splitting stops when no significant gain of regression precision can be obtained. Random forest is an ensemble algorithm that fits a number of decision trees on randomly selected features and sub-samples of the data-set, and takes the average over these trees for better predictive accuracy and to control over-fitting. A typical number of trees is 100.

Cross validation

Root mean square error (RMSE) is a commonly used metric representing the error of data fitting. Typically, regression algorithms fit the training data-set to minimize RMSE. To avoid over-fitting, it is necessary to cross-validate the performance of the model. We use 5-fold cross validation in this study. The procedure is repeated 5 times, taking different sections as test data. The final RMSE is calculated as the average RMSE of all the folds. The result gives the precision of the regression model. It is also used to set thresholds for fault detection later.

Selection of model input and output

In fitting a regression model, irrelevant inputs not only increase the computational load, but also make it harder for the algorithm to reveal true correlations between variables. We select the output and the inputs first based on physical knowledge of the system, and then cross-check with data-driven method such as forward feature selection.

More details about the algorithm applied to AHU application can be found in our publication [START_REF] Gao | Data mining and data-driven modelling for Air Handling Unit fault detection[END_REF] 3) Residuals analysis: Once we have learned the regression model, we are able to predict the output from the inputs. The difference between the predicted output and the real output is called residual. Fault detection is based on the residuals analysis.

Let X and Y be the input and output of the HVAC process. From a set of training data (x 1 , y 1 )...(x N , y N ), we use a random forest regression algorithm to estimate the function f that represents the normal behavior. Let Ŷ be the prediction output.

Ŷ = f (X) (3.17)
We apply the obtained model to test data (x N+1 , y N+1 )...(x N+M , y N+M ), and use RMSE (Root Mean Square Error) to evaluate the accuracy of the model. The regression model is fitted to the data to minimize RMSE.

RMSE = ∑ M i=N+1 ( ŷi -y i ) 2 M (3.18)
Let R be the residuals of the whole set of normal operation data. We assume that it follows Gaussian distribution that is given by

f R (r) = 1 √ 2πσ e -(r-µ) 2 /2σ 2 (3.19)
where µ is the mean, σ 2 is the variance. We have

µ ≈ 0 (3.20) σ = RMSE (3.21)
We assume that the probability of being normal (denoted as F=0) given specific r is given by:

P F|R (0 | r) = e -(r-µ) 2 /2θσ 2 (3.22)
where θ is a tolerance factor.

The probability of being normal is 1 when r = µ. The probability of being abnormal (denoted as F=1) given specific r is given by:

P F|R (1 | r) = 1 -e -(r-µ) 2 /2θσ 2 (3.23)
The tolerance factor is related to the threshold of fault detection. We choose to take 3σ as the fault detection threshold, in order to have more than 99% of the normal residuals within the threshold. If the residual is larger than the threshold, it is considered to be fault, which can be interpreted as that, the probability of being fault is larger than 50%. Based on this, we have:

e -(-3σ-µ) 2 /2θσ 2 = 0.5 (3.24)
Since µ ≈ 0, we have:

e -(-3σ) 2 /2θσ 2 = e -9/2θ = 0.5 (3.25) θ = -9 2 ln 0.5 ≈ 6.5 (3.26) 4) Relearning process: When the initial training data is limited in size and representativeness, it is helpful to run relearning process to improve model accuracy over time. When we apply the regression model learned from initial training data to new data, if the fault probability obtained in residual analysis (step 3) is less than a threshold, for example 50% as same as the fault detection threshold, the data is included in the training data. (We could also choose to have a higher threshold, for example 80%, for relearning inclusion, in order to decrease the chance of including fault data.) Then the collection of new training data is used to learn the regression model. The relearning process is repeated periodically until the accuracy doesn't improve anymore.

In practice, it is beneficial to have expert feedback to confirm or reject detected faults during operation. It helps the algorithm to make better decision on which data to include in new training data set. Model accuracy will thus be further improved.

Probabilistic model of time series correlation

For room equipment such as FCU, the output heating/cooling power is often not available.

We are not able to predict the output for given inputs and detect faults based on the prediction residual. But since the controlled variable room temperature is available, we can observe, during certain period of time, whether or not the controlled variable is reacting to the control signal. No reaction indicates failure of the equipment. The system disturbances (such as outside temperature change, solar radiation, internal heat from the occupants) and supplementary HVAC (if available) are regarded as noise in this correlation analysis.

1) Correlation calculation

In the heating case, the heat transfer in rooms fulfills the following equation:

C dT dt = Q Transmission + Q Internal + Q Ventilation + Q Heat (3.27)
where C is the thermal capacity of the room, T is the room temperature, dT/dt is the room temperature derivative by time, Q Transmission is the heat transmission from the building enclosure, related to weather disturbances, Q Internal is the internal heat gain from occupancy and equipment in the room, Q Ventilation is the heat gain from the supply air of the AHU, Q Heat is the heating power of the room heating device.

We consider Q Transmission , Q Internal , and Q Ventilation as random noise. In normal operation, dT/dt is positively correlated to Q Heat , and Q Heat is positively correlated to the heating control signal Ctr Heat . Therefore dT/dt is positively correlated to Ctr Heat . If the heating process fails, Q Heat is equal to zero, there is no correlation between dT/dt and the heating control signal Ctr Heat .

In the cooling case, the above equation becomes:

C dT dt = Q Transmission + Q Internal + Q Ventilation -Q Cool (3.28)
In normal operation, we should be able to observe a negative correlation between dT/dt and cooling control signal Ctr Cool . If the cooling process fails, Q Cool is equal to zero, there is no correlation between dT/dt and the cooling control signal Ctr Cool .

We use the Pearson correlation coefficient to evaluate the correlation between control signals and dT/dt. For two time series X and Y, the Pearson correlation is given by:

Cor(X, Y) = ∑ n 1 (x i - - x)(y i - - y ) ∑ n 1 (x i - - x) 2 ∑ n 1 (y i - - y ) 2 (3.29)
Note that this method has its limitation. If room temperature is constantly maintained at a fixed set-point, the left side of the equation is around zero, the correlation, although existing, can not be observed in the data. However in office buildings such as our use cases (chapter 4, 5), the room set-points usually change between unoccupied time and occupied time, and there is a warm-up or cool down period every morning. During this period the heating or cooling power is much larger than the other part of the heat gain or heat loss (heat transmission, internal heat, infiltration). Therefore correlations between temperature changes and heating or cooling powers of the room devices can be observed.

2) Sampling time and sliding window

The length of the time series has to be large enough to include enough data. At the same time it has to be as small as possible to identify the exact time when faults occur. In our use cases as described in 4.3 and 5.2.3, we chose 6 hours as the length the time series for correlation analysis. The raw data is first sampled to 5 minutes interval using average filter (down-sampling) or linear interpolation (up-sampling). Then for every hour, room equipment virtual evidence is extracted using data from the last 6 operating hours.

Figure 3.30 illustrates the process of correlation calculation based on real operation data from Porte de Retz building (more details in section 5.2). The first subplot shows the room temperature and heating valve command data (5-minutes sampling time). The second subplot shows the room temperature derivative and heating valve command (5-minutes sampling time). We can observe the correlation between these two signal in this plot. The third subplot shows the correlation calculation results for every hour, based on data from the last 6 operation hours.

3) Probabilistic modeling

We use a simple Gaussian model to model the distribution of correlations across all rooms.

If the data contains only or mostly normal operation, we simply split the data-set into heating and cooling to get a "pure" single Gaussian distribution centered in R+ (e.g. 0.9) for heating and R-(e.g. -0.9) for cooling. The distribution of heating / cooling failure is assumed to be Gaussian as well, and center at 0. A use case is given in 4.3.4 using simulation data, and the probability distributions are illustrated in Figure 4.8 and Figure 4.9.

If the normal and abnormal operation are mixed in our data, we are not able to get the probability distribution of correlations in normal operation directly. We assume that the room equipment heating or cooling process has two states: normal (F = 0), and failure (F = 1). And the probability distribution of correlation in both states are Gaussian distribution. We fit the correlation data with a Gaussian mixture model to get the probability distribution of each state respectively. A use case is given in 5.2.3.3 using simulation data, and the probability distributions are illustrated in Figure 5.9.

4) Fault probability calculation

From the model learned in step 3 we obtain the probability distribution of the correlations in normal case P Cor|F (x|0) and in failure case P Cor|F (x|1). The prior probabilities of normal case P F (0) and of failure case P F (1) is based on assumption in 'normal operation only' case. And in 'mixed normal and abnormal' case, the prior probabilities are obtained with the Gaussian mixture model.

Given a specific correlation Cor = x, based on Bayes rule, the probability of being normal F = 0 is given by:

P F|Cor (0|x) = P F,Cor (0, x) P F,Cor (0, x) + P F,Cor (1, x) (3.30) = P F (0)P Cor|F (x|0) P F (0)P Cor|F (x|0) + P F (1)P Cor|F (x|1)
and the probability of being fault F = 1 is given by: the root fault is preliminary more possible than others). More explanation is given in section 3.2.2.3.

P F|Cor (1|x) = P F,Cor (1, x) P F,Cor (0, x) + P F,Cor (1, x) (3.31) = P F (1)P Cor|F (x|1) P F (0)P Cor|F (x|0) + P F (1)P Cor|F (x|1)

Summary of methods to compute fault detection evidence

In practice, the prior probabilities can be set in the way that the equipment life time or expert knowledge is embedded (as in Example 2 in section 3.2.2.3), in order to treat specific root faults differently in the inference process. For example, a room valve which is just tested yesterday has much lower prior probability of failing comparing to another room valve which has not been tested in the past years. The investigation of a use case where this kind of knowledge is embedded in the prior probability may be a topic for future research.

For AHU and FCU, it is assumed that in 40% of the time they have zero heating and cooling load, 30% of the time they have heating load, and 30% of the time they have cooling load.

Within the time they have heating and cooling load, 10% of the time the load is 'high' that is over the equipment capacity. As mentioned before, in the scope of this study we don't include parent nodes of AHU and FCU heating/cooling recipient system, such as outside air temperature. It may be a topic for future research.

Since the parent nodes of Recipient System nodes are not included in this case study, the conditional probabilities for all nodes in the network are all 1 and 0 based on logic relations, as described in section 3.2.2.3.

Evidence

In this section we use the methods described in section 3.3 to obtain evidence from simulated building operation data. The focus is to demonstrate the innovative approach of integrating equipment level fault detection results into fault diagnosis Bayesian Network. Comparison of performance of different equipment level fault detection methods is not covered in this study.

Overview of evidence obtained from data

All the nodes in the Bayesian network are categorized as symptom nodes, intermediate fault nodes, and root fault nodes. All the nodes in the whole building fault diagnosis network are listed in Table 4.2. Evidence is extracted on an hourly base from data. They are marked with 'x' in the table. The methods for obtaining evidences from data are described in section 3.3. In the next sections, the results of obtaining evidence from data are illustrated and explained. The investigation focuses on operation time (7 -18) in working days.

Hard

Hard evidence

All of the hard evidence is directly extracted from the associated data following procedure described in section 3.3.1.

Controlled Variable

The room temperatures and AHU supply air temperatures are re-sampled on an hourly base using average-filter, and then compared to heating and cooling set points. For heating process the states are 'Low' and 'Normal'. For cooling process the states are 'High' and 'Normal'.

Controller fault detection

Control command is re-sampled on an hourly base using average-filter. Then for each hour, if the controlled variable is 'Low' ('High'), and the heating (cooling) control command is lower than the max output threshold (80% in this use case), the controller state is 'Fault'.

Virtual evidence: AHU heating / cooling process

Status: Failure, Normal

Method: Random forest regression model Data: Model inputs -AHU heating/cooling control signal, AHU heating/cooling coil inlet water temperature; Model output -AHU heating/cooling power.

Sampling: Data-modeling of AHU heating/cooling process uses 15-minute re-sampled data (average-filter as re-sample method). Then the residual is re-sampled again to 1-hour sampling time (with average-filter) to get hourly virtual evidence.

Step 1. learn a normality model from a dedicated commissioning procedure

First we run a commissioning test (in simulation) to collect normal operation data covering the whole range of control signal input. The control signal (input of the model) changes from 100% to 80%, 60%, 40%, 20% and 0%, each for one hour to allow for stabilization of the process, and the actual heating/cooling power (output of the model) are collected. The data is used as initial training data to train the regression model. Random forest regression is used as the modeling algorithm. Step 2. perform predictions and update the model online On the first day, the initial data model is used to predict heating/cooling power and detect fault. Then following the method described in section 3.3.2.1, training data get updated every day, the model gets more and more accurate (the band between higher and lower bound gets more and more narrow) and stabilizes after around three weeks. Then we stop updating the model. The prediction and fault detection results of the AHU heating process for the first three weeks are shown in Figure 4.5.

As we can see, the identified fault period is from 9 Jan to 10 Jan, when fault 1 'heating valve stuck' fault happens. Since no heat was given out to the supply air, the supply air temperature dropped to below set-point. In reacting to this, the controller gives 100% control command to the heating valve and stays there for the whole 'valve stuck' period. Based on this the predicted heating power stays at maximum value, while the actual heating power is around zero. Based on the equation given in section 3.3.2.1, the probability of AHU1 heating process fault given the residual obtained in step 2 are shown in Figure 4.6. This is introduced as virtual evidence into the Bayesian fault diagnosis network. Note that the AHU heating and cooling node in the Bayesian fault diagnosis network we created only include 'Failure' node. If the real heating power is larger than predicted, it is not considered as a fault. The sampling time and time window is optimized with data from simulation, as well as from real building (section 5.2.3.3), to get the best separation of two correlation distributions for heating and cooling.

The correlation between differentiated room temperature dT room dt and the heating cooling control signal is computed for every hour for every room, as described in section 3.3.2.2. The histograms of heating and cooling correlations are shown in Figure 4.8 and Figure 4.9. Heating correlations are mostly between 0 and 1, while cooling correlations are mostly between -1 and 0. A Gaussian distribution function is fitted to the data to represent the probability distribution of normal heating and cooling operation. We assume that the correlation of failed heating and cooling operation have the same standard deviation as normal operation, and has the mean at 0.

Assume the prior probability of failed operation P F (1) = 0.1, the prior probability of normal operation is P F (1) = 0.9. The conditional probability of Cor = x in normal operation and failed operation P Cor|F (x|0), P Cor|F (x|1) are obtained from the probability distribution, see The result in each room in a specific hour is located on the heat map by the x axis (room number) and y axis (time). The value of the correlation is presented in colors. If in a specific hour and a specific room the cooling or heating signal is constant (in practice, this happens only with a value of zero), no correlation is obtained, it is shown as blank on the heat map.

As we can see, during the second fault period (chilled water pump failure) on 19 July and 20 July, all rooms are in red in Figure 4.11, showing high probability of cooling process fault.

During the third fault period (room1 cooling valve stuck) from 30 July to 3 August, room1 is in red in Figure 4.11 showing high probability of cooling process fault.

On the other side, we can see that there are many red spot on the heat maps indicating high probability of heating/cooling process failure, during the hours when no fault is implemented in the simulation. This is due to the uncertainty and inaccuracy of the fault detection method. As explained in section 3.3.2.2, we consider the transmission heat, inter- nal heat gains, and ventilation heat transfer as random noise, comparing to heating cooling power of the room equipment. That is the basis of the assumption that the correlation distribution is centered in R+ (e.g. 0.9) for heating and R-(e.g. -0.9) for cooling. The assumption is proved by data in simulation case and also in real building case (section 5.2.3.3). However when this 'noise' is temporarily dominating the heat transfer, the correlation may be drifted away from the average value.

Figure 4.12 and Figure 4.13 illustrate the correlation calculation results of room 3 and room 4 in the same time period. The heating devices in both rooms are working normal. In room 3 the temperature changes are mostly caused by heating commands, therefore the calculated correlations are mostly between 0.5 and 1. However in room 4 there are many temperature changes happening when heating command was zero, most probably caused by occupancy, solar radiation, or other disturbances. In this case, the calculated correlations are close to 0, and the fault detection method generates false positive results.

Since we are using simulated data in this chapter, the room temperature and heating cooling command time series dynamics may not be fully realistic comparing to real ones. In 5.2.3.3 we will further investigate the time series correlation calculation based on real operation data in the tested building. Although the correlation distribution method has above mentioned limitation, we choose to use this method because of the limited number of sensors it requires, its tolerance to missing data, and the easiness of implementation in practice. The improvement of the room equipment fault detection method can be a topic for future research (section 6.2).

Inference results

For every time step (one hour), all evidence obtained from data is introduced into the Bayesian network, and the belief updating procedure described in section 3.1.4 is executed to calculate probabilities of all root faults. The belief updating process is realized using the SMILE reasoning engine (Pysmile) through its Python wrapper [START_REF] Tungkasthan | Automatically building diagnostic bayesian networks from on-line data sources and the smile web-based interface[END_REF].

We have investigated three different scenarios.

-Scenario 1: using symptom evidence only.

-Scenario 2: symptom evidence and controller fault detection evidence.

-Scenario 3: all evidences including HVAC fault probability virtual evidence.

The diagnosis results are listed in Table 4.3, Table 4.4, Table 4.5, and Table 4.6. The tables list symptoms observed and all the possible root faults that are direct or indirect parents of the symptom node. The ones with the highest probabilities are highlighted in the tables. The symptom is AHU1 low supply air temperature. It may be caused by AHU1 faults or hot water system (boiler, pump) faults. The latter are eliminated (the probabilities are much lower) because the other equipment served by the same system are in normal state.

Fault 1. AHU1 heating valve stuck close

Note that boiler fault gets completely eliminated (zero probability) while water pump fault does not. This is because the boiler serves many more systems (3 AHUs and 56 FCUs) than water pump 1 (only 3 AHUs), and the amount of redundant information is much greater for the boiler.

Possible root faults are AHU1 heating controller fault, heating coil mechanical fault, or high heating load. They all have same probabilities, since the network is not able to differentiate them based on only symptom evidence.

Scenario 2: include controller fault detection hard evidence

The AHU heating control command is maximum with a value of 100% which is the normal reaction expected from the controller. Therefore the associated controller fault probabilities decrease to zero. The probability of other faults become higher.

Note that while the controller fault is eliminated, the probability of pump fault is increased. However the AHU1 faults (mechanical faults or heating load high) are still much higher than pump fault (ratio of probabilities doesn't change).

Scenario 3: include HVAC fault detection virtual evidence

We further include AHU01 heating process fault probability obtained from data modeling as virtual evidence. The method for obtaining the virtual evidence is described in section 4.3.3. Based on the heating power prediction residual, the probability of AHU01 heating process fault is computed and its value is over 90%. This virtual evidence strongly supports AHU01 heating mechanical fault (heating coil, heating valve, air fan) instead of supply air system high heating load. The diagnostic result is correct. The symptom is high room temperature in 50 rooms. The belief updating results clearly shows that the root fault has a high probability to lie in the chilled water system. Chiller faults are eliminated because the AHU cooling coils served by the same chiller have normal supply air temperature (no fault symptom). The root faults are therefore narrowed down to chilled water pump 2 hydraulic system faults.

Scenario 2: include controller fault detection hard evidence

The chilled water pump command is 'on' during this period, therefore pump controller fault is eliminated. The most possible root faults are chilled water pump failure and piping system load high (can be caused by pipe block or leakage). Both root faults can cause the same effect that the chilled water is not available for FCUs, which is correctly diagnosed.

From the available data in this case study, we are not able to distinguish between these two root faults. Field investigation would be needed.

Scenario 1: only symptom evidence

The symptom is high room temperature in rooms 04, 19, and 24. The inference results are the same as for fault 3: FCU controller fault, mechanical fault (cooling coil, valve, or fan), and room high cooling load are all possible with same probabilities.

Scenario 2: include controller fault detection evidence

The FCU cooling control commands in these rooms are maximum with a value of 100% which is the normal reactions expected from the controllers. Therefore the controller faults are eliminated.

Scenario 3: include HVAC fault detection evidence FCU cooling process fault probability in room 04, 19, and 24 are computed as explained in subsection 4.3.4 and their values are between 10% and 40%. Based on these virtual evidences, the network is able to identify that the root fault is not FCU mechanical faults, but room high cooling load, which is correct.

Summary

To summarize the results, as we can see, in scenario 3 with all of the evidence, all faults are correctly diagnosed. For Fault 1 (AHU heating valve fault), Fault 3 (room FCU cooling valve fault), and Fault 4 (room FCU cooling under-dimensioned), the root faults are successfully isolated. For Fault 2 (chilled water pump failure), the possible root faults are narrowed down to two, which is equivalent to the best result that can be achieved by a human HVAC expert based on available data.

AFDD performance evaluation

The following program is developed to identify faults at every time step: 0) For all symptom nodes, identify the set of possible root fault nodes from the network structure (this is done once).

1) At every time step, compute all hard and virtual evidence from data and insert them into the network.

2) Run the inference algorithm and calculate probability of all the nodes.

3) List all symptom nodes with an abnormal state (hard evidence, e.g. low room temperature).

4) For each such abnormal symptom node, identify the root fault with highest fault probability within its associated set of root fault nodes that is obtained in step 0.

The above described process facilitate tracing root fault of specific symptom, which is very helpful in practice. In addition, it eliminates the necessity of using threshold to identify faults. (For example, based on the inference results of step 2, all nodes with more than 20% chance of failure are identified as faults.) This avoid two problems that are caused by using threshold:

-Firstly, the setting of the threshold needs to be fine tuned to reduce false positive and false negative fault detection. This makes the method less robust. -Secondly, some nodes may have relatively high probability of being fault, but much lower than another root fault which causes the same symptom. An example can be found in Fault1 scenario 3. The probability of 'hot water pump 1 pump process fault' is 29%, higher than most of the other nodes, but much lower than the probability of 'AHU1 heating coil mechanical fault', which is 59%. In this case, the 'AHU1 heating coil mechanical fault' should definitely be checked in the field first. It's not necessary to bring out the much less possible root fault, 'hot water pump 1 pump process fault'.

In another word, we should only identify the most probable root fault of a symptom as fault.

After running through the above mentioned process, we can calculate the number of hours of correct and incorrect detection of fault based on the confusion matrix, which is shown in Table 4.7.

Fault

No fault Fault detected

True positive (TP) False positive (FP) No fault detected False negative (FN) True negative (TN) The F1 score is the harmonic mean of precision and sensitivity.

F 1 = 2 • PPV • TPR PPV + TPR = 2TP 2TP + FP + FN (4.4)
ment, and to correctly identify root causes from given evidence. The accuracy of the root fault identification is related to the accuracy of the evidence. The improvement of the evidences, especially the room equipment virtual evidence, may be a topic of future research (section 6.2).

Chapter 5

Test with real operation data

Compared to simulation data, real operation data have much more noise and missing data.

In this chapter, we apply our fault diagnosis Bayesian Network to real operation data in two office buildings, to test the applicability and usability of the method in practice.

The 'GreenOValley' building test focuses on air handling unit (AHU) equipment fault diagnostics. The 'Port-de-Retz' building test focuses on room device fault diagnostics. A couple of faults are identified by manual analysis of historical data on each building, and additional ones are artificially created by manipulating the building management systems. This chapter is organized as follows. First, the collected data and the data pre-processing methods are introduced, and the faults are described. This serves as a benchmark to evaluate the performance of the new FDD method. Then, for each test building, the fault diagnosis Bayesian network implementation, evidence creation, and fault diagnosis inference results are presented. It is shown that the fault diagnosis Bayesian Network is applicable to real data and is able to automatically identify the root faults, which traditionally requires labor intensive manual analysis of historical data.

Description of test data

Data collection

To test the feasibility and the performance of the new FDD solution we developed, operation data are collected in two office buildings in France: GreenOValley building in Grenoble and Porte-de-Retz building in Nantes. Both buildings are equipped with heat pumps and air handling units (AHU) as central HVAC equipment, and fan coil units (FCU) in the rooms. More detailed information of the two buildings are given in Appendix A.

Operation data in the two office buildings are collected with BMS (Building Management System) in the following periods. The data points include temperatures, set points, control commands, power consumption, etc. They are logged in a combined 'COV' (Change Of Value) and 'Fixed Time Step' mode. Every change of value larger than the defined threshold is logged, to make sure that rapid change of values are not missed. Beside this, the values are logged once an hour to avoid too large interval between data points, when the values stay almost constant within the COV deadband. Taking room FCU data as an example, the COV threshold is 0.5 • C for room temperature, 50ppm for room CO2, and 5% for control commands.

Data pre-processing

In practice, we encountered different issues which caused wrong data or loss of data, such as power failure, change of IP configurations, loss of communication to specific equipment, defect of sensors, etc. Therefore it is crucial to clean up the data before starting with data analysis and fault detection.

In this project we use the time series analysis utility 'TSAR' written in Python developed by CSTB to clean up the data. First data are stored in defined format with standard names which are consistent with Haystack standard (standardize semantic data models and web services1 ). For each type of data, specific pre-processing methods and settings are defined in the 'TSAR' template. The data pre-processing steps include:

-Remove invalid values based on min and max value settings. For example normal room temperatures do not exceed the range of 10 -Remove frozen values based on max freeze time interval settings. For example if the logged room temperature stays unchanged for 48 hours, it is most probably caused by a sensor defect. In this case, the data within these 48 hours are removed. Note that this process is only applied to sensor data, not to control signals and set points, as we will explain below. -Re-sample to the defined time step using defined sampling method. In this study we have re-sampled all data to 5-minute time step with average filter. On strong value changes data is down-sampled, while on low or no value changes it is up-sampled. -Fill in holes by interpolation, based on interpolation method and maximum interpolation period setting. For example, if the logged room temperature is missing for 2 hours, it is filled in by linear interpolation. But if it is missing for 20 hours, linear interpolation doesn't make sense any more, the missing data will not be filled. The interpolation method is defined according to the data type. For sensor signals we use linear (first order) interpolation; for control command and set point signals we use 'fill with last value' method (zero order hold interpolation). -Control signals and set points may remain unchanged for very long time, therefore the 'remove frozen value' process based on max freeze time is not relevant. To remove frozen value of controls and set points, we reference the other points from the same data logger (usually the zone controller). More precisely, if the temperature points for some period are frozen and removed, the commands and set points of the same period are removed as well. That way, we ensure that bad data records are removed.

Two examples of data pre-processing results are illustrated in Implementation note: the 'pandas' Python library is used to represent the time series. It does not allow users to distinguish between bad, missing or not a number values, so all invalid and missing values remaining after pre-processing are implemented as NaN.

Data visualization and manual anomaly detection

The data we collected are from real building operations. There may be undiscovered or undocumented faults during operations. We choose to use traditional data visualization methods to identify existing faults. The identified faults become benchmark to evaluate the new AFDD method. A successful AFDD method is expected to have the similar capability in identifying faults as manual method, in an automatic manner.

We created the following plots to get an overview of the collected data. These plots also help us to zoom into specific abnormal devices and time periods for further investigation. The details are shown in Appendix B.

-Room temperature heat map: The room temperatures in operation hours are shown in a heat map format. The x axis indicates the room number. The y axis indicates the time. The color indicates the value of the room temperature. It gives us a quick overview of missing data period, as well as particularly cold and warm rooms or periods. -Daily energy and comfort benchmark: For specific devices, the daily average energy and comfort indicators (e.g. room temperature, heating/cooling power) are shown in scatter plots. The x-axis is the daily average outdoor temperature. This plot helps to visually identify abnormal behavior which is revealed by outliers of the benchmark profile, or outstanding profiles comparing to same type of devices.

With help of the overview generated by the above mentioned data visualization, we can zoom in to specific device and time period and create time series plot to further analyze the behavior of the device. In practice, plotting time series is the common method of analyzing historical data to identify faults. It requires expert knowledge of HVAC systems and information of the specific building. Nevertheless, it is very time consuming to find all relevant data, to select the time range, to visualize operation time and set point range, and to compare between equipment to identify abnormal behaviors. We went through this process and discovered a few faults. They are presented in the next section.

Faults description

Port-de-Retz building: faults identified by observing historical data time series

Based on the findings with room temperature heat map, we plotted multiple data time series to analyze. In the same figure, we plot all data collected by the room controller, plus the outside temperature and hot water supply temperature from other controllers. Raw data without pre-processing are used in the plots. Three faults are identified as described below.

Fault a: room heating/cooling coil valve stuck close in Room34

From the overview data visualization 5.1.3 we found out that room 34 has often low temperature.

By observing the data time series of Room 34, as shown in Figure 5.3, we found out that room temperature is not correlated with the valve signal, as can be seen in the neighboring rooms, such as Room 33. The valve signal stays at 100% (fully open) but the temperature in the room does not rise accordingly. It is a strong evidence of valve stuck close in Room 34. we found out that high room temperature occurs while cooling valve is opened to 100% (2016-7-6). After adding heat pump supply water temperature to the plot, the cause of the problem is revealed: conflicts of heating / cooling mode between the heat pump and room FCUs.

The HVAC system in the 'Port-de-Retz' building is a two-pipe system. Every room FCU is connected to one supply water pipe and one return water pipe. In summer chilled water is supplied by the heat pump and distributed in the pipes, and in winter hot water is supplied in the same pipes. The switch between heating and cooling mode for the heat pump is based on outside air temperature. At the same time, the heating / cooling mode of the room FCUs switch as well. When heat pump is in heating mode, only heating control loop is enabled in room device FCUs, and vice versa.

However in this building, the heating / cooling switch of heat pump and room devices are based on different outdoor air temperature set point or different sensors. In transition seasons sometimes it happens that, the heat pump is switched to heating mode, while the room devices are still in cooling mode. This is what happened on 2016-7-6.

The room FCU opens the valve trying to cool because room temperature is above set-point, but the heat pump is actually providing hot water. The result is that the room temperature didn't decrease but increase significantly. Similar situation occurs in room 6 on 2016-07-05, as shown in Figure 5.4, when heat pump switched to heating mode while room devices are in cooling mode. The heating case is shown in the left, the correlations are mostly between 0 and 1. The cooling case is shown in the right, the correlations are mostly between -1 and 0. Step2. Gaussian Mixture model fitting As explained in section 3.3.2.2, the objective of fitting a Gaussian Mixture model is to identify three modes from the correlations: heating, cooling, and no heat no cool.

Identifying Fault a. room heating/cooling coil valve stuck close in Room34

We investigated 2 March 2016 10am. The symptoms are room 20 low temperature and room 34 low temperature. Based on all evidence described in subsection 5.2.3, the Bayesian network calculated probability of all fault nodes. Figure 5.10 illustrates the process of tracing root causes of the symptoms. Among all root parents of a specific symptom, the one with the highest fault probability is the root fault. In the diagram, evidence nodes are marked in gray. Probability of each state of the nodes are displayed. The evidences and the inference results are shown in Table 5.4 . The identified root faults are highlighted.

Since the hot water temperature and pressure are all normal, the Bayesian network inference result shows that the root causes are in the room, either FCU mechanical function fault, or high heating load. The evidence obtained from correlation model (described in 5.2.3.3) gives that, the heating process of FCU20 has 20% chance to be fault. On the other hand, heating process of FCU34 has 99% chance to be fault. When all these evidences are entered in the network, the inference result indicates that the low temperature in room 20 is most probably caused by high room heating load (FCU20 heating load high 80%

Identifying Fault b, conflict between room FCU and heat pump heating / cooling mode, with missing data

On 6 July, the heat pump data were missing. It is unknown whether the heat pump was running or not. We investigated this case to see if the Bayesian Network is tolerant to missing data, and still be able to correctly identify that heat pump is not running correctly.

The symptoms are high temperatures in rooms 21, 33, 45, and 46. The inference results are shown in Figure 5.11. In all four rooms, the valve opens to cool down and maintain room temperature at the set point. However for all four rooms, the correlation model predicted an "inverted" mode: when the valve opens, the room is heated up instead of cooled down.

Based on this evidence as well as all others, the Bayesian Network was able to correctly identify that the heat pump is not in cooling mode (probability 90%). This indicates that the high temperature in four rooms are caused by the conflict between room FCU and heat pump heating / cooling mode.

Figure 5.11 -Retz building, building level diagnosis inference results 2 with missing data: heat pump off causing high room temperatures.

Room FCU fault detection and diagnostics overview

Beside being able to correctly identify 'Fault a' and 'Fault b', the fault diagnosis Bayesian network is able to provide an overview of all rooms for the whole monitored period of time, and reveal other potential faults. It helps facility manager to find out the most problematic rooms and set priorities of field check.

When low and high room temperatures are observed, the fault diagnosis Bayesian network is able to identify the root fault for each comfort violation: whether it is room valve fault, room high thermal load, room set point or control fault, or central heating and cooling system fault.

Room comfort violation in cold seasons: low room temperature Based on Figure 5.12 and Figure 5.13, we have the following findings:

1) Room 34 has the highest number of low temperature hours. The root causes were mostly valve fault. It verifies 'Fault a' that we identified with manual data analysis. On the other hand, it indicates a few global heat pump root faults that are not visible in other room fault diagnostics. These are the hours when heat pump is switched to cooling mode based on outside air temperature. Most of the other rooms don't have low temperature within these hours, except room 34.

2) Rooms 20 and 51 also have high number of low temperature hours. Comparing to room 34, it's more probable that the low temperature in these two rooms are caused by not enough heating power (high room heating load).

Room comfort violation in warm seasons: high room temperature Based on Figure 5.14 and Figure 5.15, we have the following findings:

1) Many rooms have big numbers of high temperature hours. In general, room 1-17 on the first floor served by heat pump 1 are in a good comfort condition. Room 18-54 served by heat pump2 has big numbers of high temperature hours, especially room 37-54 on the second floor. The root causes were mostly heat pump, especially heat pump 2. Heat pump was off, or the heating / cooling mode was conflicting with the room fan coil units. It verifies 'Fault b' that we identified with manual data analysis.

2) The big number of control error hours indicate that the control loops were not reacting fast enough to maintain room temperature at set points. 3) Room 21 has a high number of high temperature hours mainly caused by valve fault.

Test of GreenOValley building

The Bayesian network fault diagnostics method is applied to the GreenOValley building. First, the HVAC system topology and operation mode information are collected (5.3.1).

Based on this, the Bayesian network is implemented (5.3.2). Evidences are created from operation data and used for fault diagnostics (5.3.3). In the end, the fault diagnostics results are presented (5.3.4).

HVAC system topology and operation mode

GreenOValley building has two heat pumps which produce hot water and chilled water at the same time for the HVAC system through the whole year. The hot water and chilled water are delivered to the whole building by eight circulation pumps. Four pumps are for hot water serving kitchen AHU, office AHU, FCU in north offices, and FCU in south offices, respectively. The other four pumps are for chilled water serving the same zones.

The topology of the HVAC system is illustrated in Figure 5.16.

The heat pumps have fours compressors. The number of running compressors are regulated to maintain supply water temperature at the set point. The AHU heating and cooling coil valves are modulated to maintain the supply air temperature at the set point. The FCUs in rooms have heating coil and cooling coil (4-pipe system). The valves are modulated to maintain the room temperature at the set point. Every FCU is connected to an occupancy sensor, which automatically switches the operation mode and defines the room set point accordingly. If the room is occupied, the default room set point is 21 • C for heating and 26 • C for cooling. If the room is unoccupied, the default room set point is 13 • C for heating and 30 • C for cooling. In addition, the occupants in the office can adjust the set point to 3 • C higher or lower than the default value.

The GreenOValley building is operated by demand control. The heat pumps and distribution pumps are turned on and off based on the heating / cooling demand from all rooms in the building. The complexity of the control system makes it challenging to trace root causes of set point violations in the rooms and in the AHUs. Despite this complexity, the fault diagnosis Bayesian network is able to link data from different equipment and automatically reveal the root causes.

Implementation of the fault diagnosis network

Structure

The fault diagnosis network covers the heat pumps, AHU1, 2, 3, 4, and 10, and 22 selected room FCUs. The fault diagnosis network is shown in Figure 5.17 states are given by the heat pump heating / cooling mode data. 'Pump control' on/off states are directly read from data as well. 'FCU heating control' and 'FCU cooling control' disable/fault/off states are computed from the control commands, controlled variables, and set point from the procedure described in 3.3.1.3.

HVAC process nodes

In GreenOValley building, the room FCU data is limited, therefore we didn't investigate the correlation model as we did for Porte de Retz building.

On AHU04 heating coil, the data driven fault detection method described in 3.3.2.1 is implemented to provide extra pieces of evidence. Note that this method was exclusively tested on the GreenOValley building and not on Porte de Retz as it requires a dedicated commissioning test to gather enough data to create the first model.

Step 1. collecting initial training data from commissioning test A commissioning test of AHU04 heating coil was carried out on 15 Feb 2019 9AM to 12PM. The heating valve control command was manually set to 100%, 80%, 60%, 40%, and 20%, during 20 minutes for each position. It is to make sure that operation data is collected with the whole range of the control command. The collected data from the commissioning test are used as initial training data to learn a random forest regression model, to predict heating power from heating valve control command and heating coil inlet water temperature. In Figure 5.18, the heating power predicted by the random forest regression model is plotted in the upper sub-plot, together with the real heating power. The residual between predicted and real heating power is plotted in the lower sub-plot. The higher and lower bound are defined by the threshold which is three times the cross validation RMSE (Root Mean Square Error).

The cross-validation RMSE represents the model relative prediction error. It is around 1800kW, which is less than 20% of the average heating power. It indicates that the model prediction accuracy is fairly acceptable. Of course the accuracy of the prediction does not necessary imply accuracy of the fault detection, but it is an important prerequisite.

Step 2. model on-line updating

We use the initial regression model to predict heating power of the AHU04 heating coil and detect faults. After each day, new normal operation data are collected and added into the training data to learn a new random forest regression model. Since the training data-set is getting larger and larger, the regression model is getting more and more precise. After around three weeks, the regression model has converged, and the updating process is terminated.

Step 3. AHU heating fault detection

As mentioned in 5.1.4.2, On 19 Feb the heating valve of AHU04 is manually opened and closed to simulate valve stuck fault.

Figure 5.19 -GreenOValley building, AHU04, heating coil: prediction and drift detection.

(1) 8:00am to 8:40am (2) 9:00am to 9:40am (3) 15:00pm to 17:30pm

When the heating valve is stuck open from 8:00AM to 8:40AM (1), the supply air temperature increases, which makes the heating control command gradually goes to 0%. As we can see in Figure 5.19, the predicted heating power is lower than the real heating power, the residual is out of the tolerance bound which indicates a fault. From 9:00AM to 9:40AM the heating valve is stuck close (2), the supply air temperature starts to drop, and the heating control command gradually goes up to 100%. The predicted heating power is higher than the real heating power. In both cases, AHU valve stuck faults are correctly detected.

The valve was put back to normal on 9:40AM. However from 15:00PM to 17:30PM, the predicted heating power was again much higher than the real heating power (3), which indicates that heating is not working. Only by analyzing AHU data, the root cause can not be identified. By manually investigating historical data from other equipment we realized that it was caused by a hot water pump shut down accidentally/manually. This was confirmed by the facility management team. However this process is non-systematic and time consuming. This case shows the limitation of equipment level fault detection, and the value of integrating equipment fault detection results with evidence from other equipment in the Bayesian network. It will be explained in details in the later section 5.3.4.

Figure 5.20 -GreenOValley building, AHU04, heating coil: prediction and drift detection Figure 5.20 illustrates the prediction and fault detection results of a longer period. The above mentioned situation (heating valve was open but hot water pump was off) also happened on 20.Jan and 3.Feb. In addition, in the week of 21.Jan to 25.Jan, the predicted heating power is around zero (heating valve closed), but the actual heating power is much higher. It indicates value leakage or manually opening.

Step 4. calculate probabilities of being normal/fault from normalized residuals

Using the method described in 3. The most probable root fault found by the network is AHU mechanical function, which is correct. Note that on this example we clearly see that the probability values in the nodes may be low (46% here); this is not an issue as long as it is greater (with a significant margin) than all other candidate root faults, so that the ranked 1st root cause is correct.

On 19 Feb 16:00PM however, as shown in Figure 5.23, all four AHUs have low supply air temperature, and heating process failure. The root fault inferred by the network is pump turning off. This was the expected correct outcome.

The power of the Bayesian Network is to integrate different types of information from different equipment and link symptoms to root faults directly. The graphical presentation is able to show the result in a straightforward way.

Benefit of the fault diagnosis Bayesian network

Easiness of implementation based on HVAC system topology

The Bayesian network structure is based on the modular design and generalized methodology, which allows the method to be applied to wide variety of HVAC systems. The HVAC system topology and operation modes are the only information required.

Integrate operation data of all equipment in the building

In traditional building automation systems, historical data are stored individually or grouped by equipment. Investigating the root fault of certain symptom requires manual navigation between data, which is labor intensive. The fault diagnosis Bayesian network is able to integrate data from all equipment in the building and show the relationship in a straight forward network view.

Integrate maintenance information into fault diagnostics

The maintenance information can be integrated through the prior probability parameters of the Bayesian network, calculated from the age of the equipment, as described in 3.2.2.3. It is reflected in the inference results, that old equipment is more likely to have faults. We did not have the opportunity to validate this aspect on the simulated and real buildings. It may be a topic for future research.

Reveal root causes of building comfort issues

Traditional building automation systems monitor building comfort, such as room temperature, but are not able to automatically reveal the root cause of comfort issues. The fault diagnosis Bayesian network is able to calculate the most probable root cause of room temperature set point violation for every time step. An overview of fault diagnosis result over a time period, as shown in Figure 5.13, Figure 5.15, and ??, helps facility managers to identify the most problematical rooms and set priority of field investigations for possible faults.

Integrate field observations for an interactive diagnosis process

When a root cause is found, the field engineer can inspect the equipment and confirm or infirm this by inserting hard evidence on the actual state of an equipment. In case the root cause output was incorrect, updating the network with the new field evidence will reveal the next most probable root cause to inspect.

Reducing alarms

In traditional building automation system, usually all set point violations are notified as alarms, without indicating the root causes. With the fault diagnosis Bayesian network, all set point violations which are caused by one root cause will be notified as one alarm. For instance, if multiple rooms have low temperature because the hot water pump is turned off, only one alarm is notified. The overall reduction of alarms is about 10% to 30% respectively in the two test cases.

Chapter 6

Conclusion and Perspectives

In this chapter, we summarize the contributions of our study and give some perspectives of future works. The following topics are discussed: Automatic design of a Bayesian network based on building information and data-sets, the data-driven methods of setting parameters (prior probabilities and conditional probabilities), extension of the Bayesian network including more nodes and more fault classes, optimization of the room equipment correlation calculation, updating room equipment correlation distribution model along the time.

Contributions

Bayesian networks provide a good tool to simulate expert knowledge about fault diagnosis and combine it with operation data. In this study we developed a method based on Bayesian network to diagnose HVAC faults at the whole building level. There are several innovations in this method:

1) To our knowledge, this is the first time that a comprehensive method is given to deal with inter-dependencies between various components of HVAC equipment in order to perform fault diagnosis. Different types of data from different equipment are integrated at the whole building level to achieve data fusion and comprehensive fault diagnostics.

2) A generic conceptual model of HVAC sub-systems is developed. The generic expert knowledge about fault diagnosis of HVAC sub-systems is embedded in the conceptual model. Based on this model, a new modular Bayesian network structure is proposed. The structure allows for flexible configuration according to the HVAC system topology.

3) Data-driven fault detection models applied on individual HVAC equipment are used as evidence of the diagnosis Bayesian network. Two specific data-driven methods are investigated: black-box modeling and prediction for Air Handling Units, and time series correlation model for Fan Coil Units in rooms.

4) The method has been tested on data from one full scale dynamic building simulation and from two real office buildings. The method is revealed to be flexible with HVAC system topology and data availability, requires small computational effort, and provides good diagnosis accuracy.

Comparing to existing fault detection and diagnostics methods, the new method has the following benefit:

1) The modular structure and generalized methodology allow the method to be applied to a wide variety of HVAC systems and building configurations.

2) The HVAC system is diagnosed as a whole instead of individual equipment. The root faults of comfort symptoms are revealed, which helps facility managers to react to comfort problems much more efficiently.

3) The total number of alarms is reduced by grouping the root fault and all related symptoms into one alarm.

4) Facility managers can use the tool in an interactive way, which assembles human's experience in fault diagnostics.

Research perspectives

In this study we developed an HVAC fault diagnosis Bayesian network, and applied it to dynamic building simulation data and real building operation data. Initial results show good potential for building-level integrated fault diagnostics. The scope of this work leads to several potential directions for future research.

Automatic design of the Bayesian network from building information

The modular structure of the fault diagnostic Bayesian network allows automatic construction of the total building network based on building meta data, such as HVAC system topology and operation mode. Technically it requires 1) a semantic model applied to building operation data, 2) a standard library of Bayesian network modules corresponding to various HVAC equipment types, and 3) a standard library of methods to extract hard evidence and virtual evidence from data according to HVAC system operation modes.

In this study, we use a semantic model based on Haystack standard (standardize semantic data models and web services 1 ). It is integrated into the time series analysis utility 'TSAR' written in Python developed by CSTB. Every data point is stored in 'TSAR' with standard names and topology information. It provides the base of automatic generation of Bayesian network.

In order to reach an objective to automatically design the diagnostic tool, future topics may be: define the required HVAC system information and the format in the idea of standardizing the exchanges; extend model 2) and methods 3) by creating shared libraries that are able to cover various types of HVAC equipment and operation modes; explore the potential of integrating the method into BIM (Building Information Model).

Extension of the Bayesian network

In the scope of this study, we limit ourselves to only investigating binary logic causal relationships between root faults nodes and symptom nodes, as described in section 3.2.2.2. It has impact on the states of the nodes and on the methods of extracting evidence from data.

In future studies, the fault diagnostics Bayesian network can be extended to include more fault modes.

Including sensor faults may be another interesting research topic for the future. The uncertainty of the sensor data can be integrated into the Bayesian network by virtual evidence.

Bayesian network parameter setting

In this study, the prior probabilities and conditional probabilities are mostly based on simple assumptions and binary logic. The methods of setting parameters based on quantitative expert knowledge, and the influence of parameters on Bayesian network inference results may be future research topics. More concretely there are three types of parameters to be further studied:

1) Prior probabilities of root fault nodes. In this study, we introduced the method of calculating prior probabilities of faults based on the life time and age of the equipment in section 3.2.2.3. When it comes to applying the fault diagnostic Bayesian network to buildings, we assume all the prior probabilities of root faults to be 0.1. Several topics may be interesting for future research: the influence of the absolute value of prior probability to the Bayesian network inference results; different methods of estimating prior probabilities; the sensibility of fault diagnostic results to prior probabilities.

2) Conditional probabilities representing relationship between Disturbances, System Characteristic, and Recipient System nodes. In this study, we gave an example of obtaining conditional probabilities of Room Thermal Recipient System from simulation in section 3.2.1. However it is not applied to whole building Bayesian networks, because required information is not complete. It may become a topic for future research.

3) Conditional probabilities representing relationships between symptom and root fault nodes. If the Bayesian network is extended to include more fault modes as mentioned in 6.2.2, then the causal or probability relationships between root faults and symptoms are not limited to binary logic, and the methods of obtaining conditional probabilities need to be investigated. It may become a topic for future research.

Method of room equipment fault detection

In this study, we use Pearson correlation based on sliding windows to represent room equipment behavior, as described in section 3.3.2.2. Results of applying this method to building simulation data (4.3.4, 4.5) and real building operation data (5.2.3) show that the accuracy of identifying abnormal behavior has improvement potential. Recent Machine Learning techniques relying on time series similarity metrics [START_REF] Do | A multi-modal metric learning framework for time series kNN classification[END_REF] refer to Temporal Correlation (Douzal-Chouakria and Amblard, 2012) as a better alternative to Pearson Correlation to compare time series local behavior. It may be a topic for future research.

Room equipment correlation distribution model online update

In practice, regarding data availability, there are two use cases of AFDD: 1) Data is collected before the AFDD method is deployed. The objective is to reveal undiscovered faults in the past, fix them, and then continuously detect faults in the future. 2) AFDD method is deployed at the same time when data starts to be collected. The object is to continuously learn and detect faults in the future.

Our study belongs to the first use case, where large amount of data is already available when the AFDD method is deployed. For the second use case, the AFDD method has to start working with limited data. In our method, the part that requires history data is to obtain virtual evidence based on data modeling of HVAC equipment. We have developed two methods: 1) For central equipment (e.g. AHU), we learned regression model initially with data collected in a commissioning test, and relearned it while gradually including more data in the training set. This method is applicable to both use cases 1 and 2.

2) For room equipment (e.g. FCU), we learned correlation distribution model based on a data-set covering all rooms in almost a whole year (section 4.3.4 using simulation data, section 5.2.3.3 using real building data). The method is primarily applicable to use case 1, but has good potential to be extended to use case 2, as explained below.

With data from a real building Port-de-Retz (section 4), we investigated the correlation distribution based on 2 weeks of data, 4 weeks of data, up to the whole set of data. As we can see in Figure 6.1, the distribution of correlation almost never changes no matter how much data is collected (with the precondition that no faults have been fixed during the period of data collection). Based on this we know that 2 weeks of data from heating season and cooling season respectively are able to represent the distribution of the correlation. Therefore a relearning process that starts with initial data of 2 weeks and gradually include more data is realistic. The development of this enhanced method may be a potential research topic for the future.

Performance test of the fault diagnostics Bayesian network

In the scope of this study, we evaluated the fault diagnostics accuracy in simulated building case (4.5). For the real buildings, we only verified the fault diagnostics results for a few specific equipment at a specific time (5.2.4, 5.3.4). The results show that the Bayesian network is able to correctly detect faults and identify the root cause.

In future study it would be interesting to evaluate the overall fault diagnostics accuracy by calculating the n-class confusion matrix. The robustness of the method against missing data could also be a topic for future research.

Applications perspective

The development of the method aims at implementation in the industry. The method integrates data from different equipment, of different types and time range into a single framework, and gives a comprehensive fault diagnosis results. It can help facility managers to save a lot of time and effort in practice. Towards an industrial implementation we have the following perspectives.

1) Programming the structure of the diagnosis Bayesian network. The modular blocks of the Bayesian network correspond to different HVAC equipment and the controlled system. A library of typical applications can be created. When constructing a diagnosis Bayesian network for a specific building, the modular blocks corresponding to each HVAC equipment in the building are selected from the library, and simply connected together based on system topology.

2) Setting parameters of the diagnosis Bayesian network. If not much information is available, set all the prior probabilities of fault nodes to be the same. Parent nodes of 'system load' nodes can be ignore if it's not easy to get accurate conditional probabilities. In this way, the network is going to generate the most 'common sense' results. If the results need to bias in the way that some specific faults are more often than other faults, the prior probabilities can be tuned, and the conditional probabilities of 'system load' nodes can be added.

B.1.3 Central equipment daily energy benchmark

The scatter plots of daily average heating/cooling power versus outdoor temperature are shown in Figure B.6. Generally, the heating/cooling power is the lowest when outside temperature is between 10 • C and 20 • C. Heating power is needed when the outside temperature is low. Cooling power is needed when the outside temperature is high.

We can see that the heating power of 'Floor 2 Office South' zone is much higher than 'Floor 1 Office North' zone and 'Floor 1 Office South' zone. At the same time we see from Since the data was collected from October 2018 to June 2019, and summer is not included, the rooms are mostly in heating mode, with the temperatures maintained around heating set point. As we can see in the scatter plot, most of the rooms have the heating set point at 21 • C. However, in a few room, such as E0C3-006, E1C1-007, E1C3-085, and E3C3-040, the heating set point is often reduced, which indicate that the rooms were unoccupied. As for temperature control, most of the rooms are able to maintain the room temperature at the set point.

B.2.2.2 Room heating and cooling command scatter plot

The daily average room heating and cooling commands in operation hours (work days from 8 o'clock to 18 o'clock) are shown in the scatter plot in Figure B.9. The x-axis is the daily average outdoor temperature.

Since the data was collected from October 2018 to June 2019, and summer is not included, most of the rooms only had heating commands. As we can see, in some rooms such as E1C1-007, E1C2-021, and E1C2-027, the heating command often went up to 100%. It may indicate that the heating capacity is not enough in these rooms.

  I love you with all my heart! A.1 Green O Valley building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.1 Building plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.2 Building envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.3 HVAC system: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.4 HVAC system: Heating and cooling generation . . . . . . . . . . . . . A.1.5 HVAC system: Hot water and chilled water distribution . . . . . . . . A.1.6 HVAC system: Ventilation system . . . . . . . . . . . . . . . . . . . . . A.1.7 HVAC system: Room heating and cooling device . . . . . . . . . . . . A.2 Porte de Retz building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.1 Building plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.2 Building envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.3 HVAC system: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . B Data visualization of test buildings B.1 Porte-de-Retz building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.1.1 Room temperature heat map . . . . . . . . . . . . . . . . . . . . . . . . B.1.2 Room device daily operation benchmark . . . . . . . . . . . . . . . . . B.1.3 Central equipment daily energy benchmark . . . . . . . . . . . . . . . B.2 GreenOValley building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2.1 Room temperature heat map . . . . . . . . . . . . . . . . . . . . . . . . B.2.2 Room device daily operation benchmark . . . . . . . . . . . . . . . . . B.2.3 Central equipment daily energy benchmark . . . . . . . . . . . . . . . Bibliography List of Figures 1.1 Causes of building performance gap . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Number of faults in building's life cycle . . . . . . . . . . . . . . . . . . . . . . 1.3 Alarm list of a chiller from the manufacture TRANE. . . . . . . . . . . . . . . 1.4 Example of BMS system, EcoStruxure™ Building Operation from Schneider Electric. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Fault detection system topology and alarms data processing principles . . . . 1.6 Structure of the new fault detection solution . . . . . . . . . . . . . . . . . . . 2.1 Classification scheme for AFDD methods . . . . . . . . . . . . . . . . . . . . . 2.2 Diagram of real time energy diagnostics System, O'Neill et al., 2011 . . . . . . 2.3 Demonstration building Vaucanson, Béguery et al., 2017. Model in IDA-ICE 3D view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Demonstration building Vaucanson, Béguery et al., 2017. Fault detection tool user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Bayesian network for the 'wet grass' example. . . . . . . . . . . . . . . . . . . 3.2 Inference results of Example 1-2: left (a), right (b) . . . . . . . . . . . . . . . . .

Figure

  Figure 1.1 -Causes of building performance gap

Figure 1

 1 Figure 1.2 -Number of faults in building's life cycle

  Figure 1.3 gives an example of HVAC equipment alarms.

Figure 1 . 3 -

 13 Figure 1.3 -Alarm list of a chiller from the manufacture TRANE.

Figure 1 . 4 -

 14 Figure 1.4 -Example of BMS system, EcoStruxure™ Building Operation from Schneider Electric.

Figure 1

 1 Figure 1.6 -Structure of the new fault detection solution

  . In the final report of the AFDD commercialization program, they summarized a few AFDD demonstration tools, and evaluated the commercialization potential. Investigated algorithms include AHU and chiller rule-based AFDD solutions (APAR) developed by the National Institute of Standard and Technology (NIST), and the Rooftop unit diagnostics solutions developed by Purdue, Honeywell, and Carrier. More details of the algorithms are given in section 2.1.2. Katipamula published a comprehensive review on AFDD for building system in 2005 (Katipamula and Brambley, 2005a,b), and a second review in 2018 (Kim and Katipamula, 2018). He categorized AFDD research methods into three groups: (1) Quantitative model-based, (2) Qualitative model-based, and (3) Process history based.

Figure

  Figure 2.1 -Classification scheme for AFDD methods(Katipamula and Brambley, 2005a)

Figure 2 . 3 -

 23 Figure 2.3 -Demonstration building Vaucanson, Béguery et al., 2017. Model in IDA-ICE 3D view.

Figure 2 . 4 -

 24 Figure 2.4 -Demonstration building Vaucanson, Béguery et al., 2017. Fault detection tool user interface

Figure 3

 3 Figure 3.2 -Inference results of Example 1-2: left (a), right (b)

Figure 3 . 4 -

 34 Figure 3.4 -Concept model of Room radiator system

Figure 3 . 5 -

 35 Figure 3.5 -The heat load distribution of Building Enclosure normal case (left) and fault case (right)

  The above mentioned causal and probabilistic relationships are represented by the Bayesian Network shown in Figure3.6. The Room Temperature is the symptom node of the room radiator system. The state of Room Temperature is related to all three components of the system: Controller, Radiator, and Room. The causes of different states of the components are shown on top of the blocks in Figure3.6. They are included in the Bayesian Network accordingly. Valve, Heat Exchanger and Building Enclosure are component properties that belong to the system. In contrast, Hot Water Temperature, Hot Water Pressure, and Weather are external inputs and illustrated outside the system. Later we will see that Hot Water Temperature and Hot Water Pressure are symptom nodes of energy source systems. They provide the connections between HVAC sub-systems at building-level. We will see this in the example given in section 3.2.4.

Figure 3

 3 Figure 3.6 -Fault diagnosis Bayesian Network of a room radiator system

Figure 3 . 7 -

 37 Figure 3.7 -Generic concept model of HVAC sub-systems

  Figure 3.7, the state of each block can be observed by the local inputs and the output associated with this block, shown as horizontal signals in the block flow diagram. Methods of obtaining the state from data will be explained in section 3.3. The properties and the external inputs are shown as vertical signals on top of the blocks. They are the causes of different states of the blocks. Each block and vertical signal transforms into a node in the Bayesian Network as shown in Figure 3.8.The state of the whole sub-system is indicated by its output, controlled variable, compared to its input set point. The binary node Controlled Variable is the symptom node of the HVAC sub-system. Controller, HVAC, and Recipient System are the fault nodes that cause the symptom. Among the three fault nodes, HVAC and Recipient System have parent nodes, which indicate that the fault may be caused by other root faults. The root faults are shown as optional because they are not always present in all applications. Examples of specific HVAC sub-systems are given in section 3.3.

Figure 3 . 8 -

 38 Figure 3.8 -Fault detection Bayesian network of an HVAC sub-system. Dotted lines indicate optional nodes.

Figure 3 .

 3 Figure 3.11 -Fault diagnosis Bayesian network of a hot water boiler system

Figure 3 .

 3 Figure 3.14 -Example of VFD pump curve

Figure 3 .

 3 Figure 3.15 -Concept model of constant air flow ventilation system

Figure 3 .

 3 Figure 3.19 -Room radiator system fault diagnosis network concept

Case 2 .

 2 Figure 3.20 -Room radiator system fault diagnosis inference case 1

Figure 3 .Case 4 .

 34 Figure 3.22 -Room radiator system fault diagnosis inference case 3

Figure 3 .

 3 Figure 3.24 -Room radiator system fault diagnosis inference case 5

Figure 3 .

 3 Figure 3.26 -Fault detection Bayesian network of an HVAC sub-system. (Dotted lines indicate optional nodes.)

Figure 3 .

 3 Figure 3.27 -Controlled variable hard evidence: Porte de Retz building FCU28 room temperature

Figure 3 .

 3 Figure3.27 illustrates the temperature and set point collected in one room of a real office building (Porte-de-Retz, details in 5.2). The room temperature set point is given by the room unit (an example of room unit is given in Figure3.28). The default set point is 21 • C in heating mode, and 26 • C in cooling mode. The room occupants can increase or decrease the set point a few degree from the default value, using the room unit. As shown in Figure3.27, the set point is at default value in unoccupied time, and in occupied time it switches to the value which is defined by the occupants. In the first two and half days, the heating set point was 20 • C, then the occupants increased the set point to 24 • C. The room temperature comfort band is marked in green shade, room temperature tolerant band is marked in yellow shade. The unoccupied time (night time) is marked in gray shade.

1

  . Sampling: Continuous room temperature and set point data (as shown in the first subplot of Figure 3.27) are sampled to one hour using average filter (as shown in the second subplot of Figure 3.27).

Figure 3 .

 3 Figure 3.29 -Controller hard evidence: Porte de Retz building FCU28 heating control

Figure 3 .

 3 Figure 3.30 -Room equipment virtual evidence: Porte de Retz building FCU28 heating process

Figure 4 .

 4 Figure 4.2 -Simulated Green-O-Valley building block diagram

Figure 4 .

 4 4 shows the prediction results of the AHU heating process regression model obtained from initial training data.

Figure 4 . 4 -

 44 Figure 4.4 -Commissioning test and prediction with initial model of AHU heating process

Figure 4 . 5 -

 45 Figure 4.5 -On-line updated prediction and fault detection of AHU heating process

Figure 4 .

 4 Figure 4.6 -Probability of AHU1 heating process fault As we can see, the probability of fault is around 1 in the first fault period (AHU heating valve stuck) 9 Jan and 10 Jan, and below 0.5 on most of the other days. The other peaks

Figure 4 . 7 -

 47 Figure 4.7 -Prediction and fault detection of AHU heating process, zoom into one day.

  Correlation distribution modelData: FCU heating/cooling control signal, room temperature Sampling: We use data in 5-minute time step and calculates time series correlation during the last six hours. The calculation is executed for each hour.

Figure 4 .

 4 8 and Figure 4.9. Then the probabilities of heating/cooling failure are calculated with Equation 3.31. The results are shown in the heat map figure Figure 4.10 and Figure 4.11.

Figure 4 .

 4 Figure 4.8 -The probability distribution of correlations, room temperature derivative v.s. heating command.

Figure 4 .

 4 Figure 4.9 -The probability distribution of correlations, room temperature derivative v.s. cooling command.

Figure 4 .

 4 Figure 4.10 -Probability of room heating process failure

Figure 4 .Figure 4 .

 44 Figure 4.12 -Correlation between room temperature derivative and heating command in room 3

GreenOValley

Figure 5 .

 5 1 and Figure 5.2. Figure 5.1 shows that the invalid room temperatures on 20.04.2016, 21.04.2016, and 02.05.2016 are corrected after data pre-processing.Figure 5.1 shows that the invalid values on 20.04.2016 are corrected; the frozen values from 22.04.2016 to 01.05.2016 are removed.

Figure 5 .

 5 Figure 5.1 -Data pre-processing of room temperature data (1)

  Figure 5.3 -During heating season, room 34 valve stuck close compared to Room 33 normal.

Figure 5 . 4 -

 54 Figure 5.4 -Heat pump heating / cooling mode reversed, observed in Room 21 and Room 6

Figure 5 .

 5 Figure 5.6 -Fault diagnosis network of Port-de-Retz building

Figure 5 . 7 -

 57 Figure 5.7 -Retz building room time series correlation heat map

Figure 5 .

 5 Figure 5.10 -Retz building, building level diagnosis inference results 1: valve faults causing low room temperatures.

Figure 5 .

 5 Figure 5.12 -Retz building, room comfort (normal or low temperature) in each room and the root causes.

Figure 5 .

 5 Figure 5.13 -Retz building, number of hours of room low temperature and the root causes.

Figure 5 .

 5 Figure 5.12 illustrates low room temperature comfort violation in every room and every hour, and Figure 5.13 gives the total number of hours of low room temperature in each

Figure 5 .

 5 Figure 5.14 -Retz building, room comfort (normal or high temperature) in each room and the root causes.

Figure 5 .

 5 Figure 5.14 illustrates high room temperature comfort violation in every room and every hour, and Figure 5.15 gives the total number of hours of high room temperature in each room. In both figures, the hours of comfort problem caused by different root causes are marked with different colors.

Figure 5 .

 5 Figure 5.15 -Retz building, cooling season, number of hours of room high temperature and the root causes.

Figure 5 .

 5 Figure 5.16 -HVAC system topology of GreenOValley building

  . The heat pumps have heating and cooling function at the same time. It is represented by two sub-systems in the Bayesian network.

Figure 5 . 17 -

 517 Figure 5.17 -Fault diagnosis network of GreenOValley building

Figure 5 .

 5 Figure 5.18 -GreenOValley building, AHU04, heating coil: commissioning test and collection of initial training data

  3.2.1, we calculated the probability of failure from the prediction residuals. The results of 19 Feb are shown in Figure 5.21. The probabilities are integrated as virtual evidence into the fault diagnosis Bayesian network.

Figure 5 .

 5 Figure 5.21 -GreenOValley building, AHU04, heating coil, probability of failure

Figure 5 .

 5 Figure 5.22 -GreenOValley building, building level diagnosis inference results 1: AHU04 mechanical fault (valve) causing low supply air temperature.

Figure 5 .

 5 Figure 5.22 shows the inference results from the data of 19 Feb 9:15AM. When integrating data for the whole building, we see that only AHU04 has a fault symptom. It is low supply air temperature caused by failure of the AHU heating process. (Virtual evidence of 100% being fault as we already saw in Figure5.21.) The most probable root fault found by the network is AHU mechanical function, which is correct. Note that on this example we clearly see that the probability values in the nodes may be low (46% here); this is not an issue as long as it is greater (with a significant margin) than all other candidate root faults, so that the ranked 1st root cause is correct.

Figure 5 .

 5 Figure 5.23 -GreenOValley building, building level diagnosis inference results 2: AHU01, 02, 03, 04, circulation pump turned off causing low supply air temperature.

Figure 6

 6 Figure 6.1 -Update of correlation distribution model every two weeks. Data from real building Port-de-Retz.

Figure A. 3 -

 3 Figure A.3 -Parameters of thermal bridges in Green O Valley building

Figure A. 4 -

 4 Figure A.4 -HVAC system topology of Green O Valley building

  Figure B.1 that the room temperature is higher in 'Floor 2 Office South' zone. It indicates that excessive heating energy is used on the second floor because of overheating.

Figure B. 6 -

 6 Figure B.6 -Daily energy benchmark of Porte-de-Retz building

Figure B. 7 -

 7 Figure B.7 -Room temperature heat map, GreenOValley building

Figure B. 9 -

 9 Figure B.9 -Room heating and cooling command scatter plot, GreenOValley building

  Concept model of Room radiator system . . . . . . . . . . . . . . . . . . . . . . 3.5 The heat load distribution of Building Enclosure normal case (left) and fault case (right) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Fault diagnosis Bayesian Network of a room radiator system . . . . . . . . . . 3.7 Generic concept model of HVAC sub-systems . . . . . . . . . . . . . . . . . . . 3.8 Fault detection Bayesian network of an HVAC sub-system. Dotted lines indicate optional nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Fault probability of an equipment increased with years in operation. . . . . . .13 Fault diagnosis Bayesian network of a pump hydraulic system . . . . . . . . . 3.14 Example of VFD pump curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15 Concept model of constant air flow ventilation system . . . . . . . . . . . . . . 3.16 Fault diagnosis Bayesian network of constant air flow ventilation system . . . 3.17 Concept model of a chiller chilled water system . . . . . . . . . . . . . . . . . 3.18 Fault diagnosis Bayesian network of a chiller chilled water system . . . . . . . 3.19 Room radiator system fault diagnosis network concept . . . . . . . . . . . . . 3.20 Room radiator system fault diagnosis inference case 1 . . . . . . . . . . . . . . 3.21 Room radiator system fault diagnosis inference case 2 . . . . . . . . . . . . . . 3.22 Room radiator system fault diagnosis inference case 3 . . . . . . . . . . . . . . 3.23 Room radiator system fault diagnosis inference case 4 . . . . . . . . . . . . . . On-line updated prediction and fault detection of AHU heating process . . . 4.6 Probability of AHU1 heating process fault . . . . . . . . . . . . . . . . . . . . . 4.7 Prediction and fault detection of AHU heating process, zoom into one day. . . 4.8 The probability distribution of correlations, room temperature derivative v.s. heating command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 The probability distribution of correlations, room temperature derivative v.s. cooling command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Correlation between room temperature derivative and heating command in room 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Data pre-processing of room temperature data (1) . . . . . . . . . . . . . . . . 5.2 Data pre-processing of water temperature data (2) . . . . . . . . . . . . . . . . 5.3 During heating season, room 34 valve stuck close compared to Room 33 normal.111 5.4 Heat pump heating / cooling mode reversed, observed in Room 21 and Room 5.5 HVAC system topology of Port-de-Retz building . . . . . . . . . . . . . . . . . 5.6 Fault diagnosis network of Port-de-Retz building . . . . . . . . . . . . . . . . 5.7 Retz building room time series correlation heat map . . . . . . . . . . . . . . . 5.8 Retz building room time series correlation histogram . . . . . . . . . . . . . . 5.9 Probability distribution of correlations fit to Gaussian Mixture Model . . . . . Construction plan of Green O Valley building . . . . . . . . . . . . . . . . . . . A.2 Simulation of windows shades in Green O Valley building . . . . . . . . . . . A.3 Parameters of thermal bridges in Green O Valley building . . . . . . . . . . . A.4 HVAC system topology of Green O Valley building . . . . . . . . . . . . . . . A.5 Heat pumps in Green O Valley building, BMS graphics. . . . . . . . . . . . . . A.6 AHUs for the office area in Green O Valley building, BMS graphics. . . . . . . A.7 Construction plan of Porte de Retz building . . . . . . . . . . . . . . . . . . . . A.8 Envelope properties of Porte de Retz building . . . . . . . . . . . . . . . . . . A.9 HVAC system topology of Port-de-Retz building . . . . . . . . . . . . . . . . . B.1 Room temperature heat map, Porte-de-Retz building . . . . . . . . . . . . . . Summary of data driven AFDD studies, part 1. . . . . . . . . . . . . . . . . . . 2.2 Summary of data driven AFDD studies, part 2. . . . . . . . . . . . . . . . . . .

	List of Tables AFDD Automatic Fault Detection and Diagnosis 2.1 Abbreviations Chapter 1
	HVAC		Heating Ventilation and Air Conditioning
	BMS		Building Management System
	VAV		Variable Air Volume
	PI control Proportional-Integral control
	COP		Coefficient Of Performance
	PCA		Principle Component Analysis
	SVR		Support Vector Regression
	KPCA		Kernal Principle Component Analysis
	SPE		Squared Prediction Error
	SVM		Support Vector Machine
	DT		Decision Tree
	ANN		Artificial Neural Network
	LR		Linear Regression
	AR		Auto-Regressive
	ARX		Auto-Regressive Exogenous
	NA		Not available
	EWMA	Exponentially Weighted Moving Average
	TFDK		Tree-structured Fault Dependence Kernel
	BN		Bayesian Network
	SAX		Symbolic Aggregate Approximation
	PMF		Probability Mass Function
	AHU		Air Handling Unit
	HMI		Human Machine Interface
	FCU		Fan Coil Unit
	MTBF		Mean Time Before Failure
	5.19 GreenOValley building, AHU04, heating coil: prediction and drift detection. VFD Variable Frequency Drive
	RMSE	(1) 8:00am to 8:40am (2) 9:00am to 9:40am (3) 15:00pm to 17:30pm . . . . . . . Root Mean Square Error
	COV 5.20 GreenOValley building, AHU04, heating coil: prediction and drift detection . Change Of Value BIM Building Information Model
	5.21 GreenOValley building, AHU04, heating coil, probability of failure . . . . . .
	5.22 GreenOValley building, building level diagnosis inference results 1: AHU04
		mechanical fault (valve) causing low supply air temperature. . . . . . . . . . .
	5.23 GreenOValley building, building level diagnosis inference results 2: AHU01,
		02, 03, 04, circulation pump turned off causing low supply air temperature. .

Example 1-2: left (a) virtual evidence 10% rain, 90% no rain; (b) virtual evidence 1% rain, 99% no rain; . . . . . . . . . . . . . . . . . . 3.4 3.10 Concept model of a hot water boiler system . . . . . . . . . . . . . . . . . . . . 3.11 Fault diagnosis Bayesian network of a hot water boiler system . . . . . . . . . 3.12 Concept model of a pump hydraulic system . . . . . . . . . . . . . . . . . . . . 33.24 Room radiator system fault diagnosis inference case 5 . . . . . . . . . . . . . . 3.25 Room radiator system fault diagnosis inference case 6 . . . . . . . . . . . . . . 3.26 Fault detection Bayesian network of an HVAC sub-system. (Dotted lines indicate optional nodes.

) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.27 Controlled variable hard evidence: Porte de Retz building FCU28 room temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.28 Example of a room unit of fan coil unit. . . . . . . . . . . . . . . . . . . . . . . 3.29 Controller hard evidence: Porte de Retz building FCU28 heating control . . . 3.30 Room equipment virtual evidence: Porte de Retz building FCU28 heating process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Simulated GreenOValley building system topology . . . . . . . . . . . . . . . 4.2 Simulated Green-O-Valley building block diagram . . . . . . . . . . . . . . . . 4.3 Simulated Green-O-Valley building diagnostic network . . . . . . . . . . . . . 4.4 Commissioning test and prediction with initial model of AHU heating process 4.5 4.10 Probability of room heating process failure . . . . . . . . . . . . . . . . . . . . 4.11 Probability of room cooling process failure . . . . . . . . . . . . . . . . . . . . 4.12 Correlation between room temperature derivative and heating command in room 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45.10 Retz building, building level diagnosis inference results 1: valve faults causing low room temperatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11 Retz building, building level diagnosis inference results 2 with missing data: heat pump off causing high room temperatures. . . . . . . . . . . . . . . . . . 5.12 Retz building, room comfort (normal or low temperature) in each room and the root causes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.13 Retz building, number of hours of room low temperature and the root causes. 5.14 Retz building, room comfort (normal or high temperature) in each room and the root causes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.15 Retz building, cooling season, number of hours of room high temperature and the root causes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.16 HVAC system topology of GreenOValley building . . . . . . . . . . . . . . . . 5.17 Fault diagnosis network of GreenOValley building . . . . . . . . . . . . . . . . 5.18 GreenOValley building, AHU04, heating coil: commissioning test and collection of initial training data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Update of correlation distribution model every two weeks. Data from real building Port-de-Retz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1 B.2 Room temperature and set point scatter plot, Porte-de-Retz building . . . . . B.3 Room temperature and set point scatter plot, Porte-de-Retz building . . . . . B.4 Room heating and cooling command scatter plot, Porte-de-Retz building . . . B.5 Room heating and cooling command scatter plot, Porte-de-Retz building . . . B.6 Daily energy benchmark of Porte-de-Retz building . . . . . . . . . . . . . . . . B.7 Room temperature heat map, GreenOValley building . . . . . . . . . . . . . . B.8 Room temperature and set point scatter plot, GreenOValley building . . . . . B.9 Room heating and cooling command scatter plot, GreenOValley building . . B.10 Daily energy benchmark of AHUs, GreenOValley building . . . . . . . . . . . B.11 Daily energy benchmark of heat pumps, GreenOValley building . . . . . . . . 3.1 Room temperature in condition of three components of the room radiator system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Root causes of radiator failure. Valve and heat exchanger fault refer to valve stuck close or heat exchanger blockage. . . . . . . . . . . . . . . . . . . . . . . 3.3 Conditional probabilities of Room node in the room radiator system, obtained from simulation results as an example. . . . . . . . . . . . . . . . . . . . . . . . 3.4 Conditional probabilities of Controlled Variable . . . . . . . . . . . . . . . . . . 3.5 Conditional probabilities of 'HVAC' . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Summary of HVAC sub-system fault diagnostics Bayesian Networks . . . . . 3.7 Prior probabilities of root fault nodes in the room radiator system application 3.8 Prior probabilities of the disturbance node in the room radiator system application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Conditional probabilities of Room node in the room radiator system application. 3.10 Conditional probabilities of Hot Water System node in the room radiator system application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 Conditional probabilities of Piping System node in the room radiator system application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12 Fault diagnosis inference results. The objective of the inference process is to get an updated probability for all root fault nodes. Posted evidence is marked in gray. Root faults are marked in red. Most probable faults are in dark red color, and less probable faults are in light red color. . . . . . . . . . . . . . . . 3.13 Methods and required data for obtaining hard evidence . . . . . . . . . . . . . 3.14 Methods and required data for obtaining virtual evidence (* indicates optional data.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Prior probabilities of root fault nodes in the whole building test case . . . . . 4.2 Overview of the evidence in the Green-O-Valley simulation case study. . . . . 4.3 Fault diagnosis results of fault 1: AHU1 heating valve stuck close . . . . . . . Introduction This thesis proposes a new Automatic Fault Detection and Diagnosis (AFDD) method for buildings based on operation data collected by Building Management Systems (BMS). The method uses Bayesian Networks to integrate data from different components of the Heating Ventilation and Air-conditioning (HVAC) system, including equipment-level data-driven fault detection results, to achieve integrated fault diagnosis and information fusion. The introductory part of this work provides general background on the importance of building fault detection and diagnosis tools. It is followed by a state of art of existing AFDD solutions in the industry and their limitation, leading to the motivation behind this thesis and its main contributions.

  International Energy Agency (IEA) Annex, 0071 provided methods of conducting building energy performance assessment based on in-situ measurements. Van Dronkelaar et al., 2016 investigated the underlying causes of energy performance gap in non-domestic buildings. De Wilde, 2014 provided a framework to investigate the gap between predicted and measured energy performance.

  set point, it indicates a controller fault. Controller faults include controller failure, control algorithm error, and wrong control parameters, e.g. inappropriate Proportional-Integral (PI) controller parameters causing system oscillation. In practice, this kind of faults may exist for a very long time without being noticed, as long as no one complains about comfort problems. Controller faults are usually fixed by control specialists, e.g. installer or integrator of the building automation system.

Control faults:

If the BMS controller is not giving appropriate signals to operate the equipment, for example, if the radiator valve is not commanded to open when room temperature is far below

  9 . The latter is also integrated in EcoStruxure™ Building Advisor from Schneider Electric 10 . Both systems connect to BMS, EMS, and other building systems through communication protocols, obtain online data, and run cloud-based automatic fault detection programs.SkySpark provides an open platform, which allows facility managers to program automatic fault-detection rules. For example, they can generate an alarm if AHU supply-air temperature is not higher than mix-air temperature when heating valve is open, indicating valve command failure or hot water unavailability. Clockworks is a cloud-based service of remote assistance by in-house engineers, relying on physical and data-driven models tailored to each building during commissioning.

5. https://www.se.com/fr/fr/product-range/62111-ecostruxure™-building-operation 6. http://w5.siemens.com/france/web/fr/sbt/ee/solutions-gestion-techniquebatiment/desigo/pages/systeme-desigo.aspx 7. https://www.buildingcontrols.honeywell.com/Building-Automation-Systems/WEBs-N4-Software-Platform 8. https://skyfoundry.com/skyspark/ ing

  If only normal operation data is available, regression methods can be used to predict one of the variable Y from other variables X. Then the learned model is applied to new data set (test data), if the prediction of output ŷ is far from the real output y, it indicates a fault. The modeling methods include linear regression (LR), auto-regressive exogenous model (ARX), random forest regression, etc.

	2)
	The process history-based AFDD methods have attracted a lot of research attention because
	they require less expert knowledge and because of their reduced modeling complexity. The
	methods are categorized as gray box methods and black box methods. Black box methods
	include supervised learning and unsupervised learning as described below (The notation is
	based on The elements of statistical learning, Friedman, Hastie, and Tibshirani, 2001).
	Supervised learning: Given the value of an input vector X, make a good prediction of the
	quantitative output Y (regression), or the qualitative (categorical) output G (classification).
	The prediction of Y is denoted by Ŷ (pronounced "Y-hat"); likewise for G, the prediction is
	denoted by Ĝ. In fault detection applications, there are several different methods based on
	supervised learning:
	1) If labeled normal operation data and abnormal operation data are both available, classi-
	fication methods are applicable. Let X represent the process variables, and G represent the
	category being normal or abnormal. Supervised classification methods learn from existing
	data (training data), and predict for new data (test data) whether it belongs to normal case
	or abnormal case. Various algorithms can be used, such as support vector machine (SVM),
	decision tree (DT), and Artificial Neural Network (ANN), etc.

Table 2

 2

	.1 and Table 2.2 list the algo-

Table 2 .

 2 1 -Summary of data driven AFDD studies, part 1.

	Fault diagnostics	Variable contribu-	tion	Variable contribu-	tion		Variable contribu-	tion		(included in fault	detection step)		NA		Residual analysis,	expert rules	(included in fault	detection step)	(included in fault	detection step)	Subtractive Clus-	tering, fault library,	then match new	data to the known	clusters
	Pre-processing Fault detection		NA PCA, SPE		Savitzky-Golay filter PCA, SPE		NA (15min sample) PCA, SPE		NA Piece wise ARX	NA Change of parame-ter of recursive ARX	NA ARX, EWMA con-trol chart	Filter out transient Decision tree, CART	state data for tree pruning	Wavelet based de-Decision tree, 8 fault types, misclassifica-noising, Modified tion cost as learning Thompson's Tau objective	Wavelet based de-ANN regression	noising, logical fea-model trained with	ture selection based operation normal	on control loop data
	Fault type Key method	Mechanical, PCA control	Mechanical PCA		NA PCA		Window ARX open		Mechanical ARX		Sensor, ARX stuck valve	Control, Decision	mechanical tree	Mechanical Decision tree	Sensor, ANN stuck valve
	System	AHU	(ASHRAE	RP-1312)	Chiller		Chiller		Room radi-	ator	Residential	HVAC	VAV	AHU	(ASHRAE	RP-1312)	Chiller	(ASHRAE	RP-1043)	AHU
	Test	Data		C, M		C, M		C, M		-		-		C, M		C, M	C, M	C, S
	Training	Data		N, M		N, M		N, M		C, M		C, S		N, M		C, M	C, M	C, S
	Item	Xiao et al.,	2009	Beghi et al.,	2016	Cotrufo	and	Zmeure-	anu, 2016	Ajib et al.,	2017	Turner,	Staino, and	Basu, 2017	Wang and	Chen, 2016	Yan et al.,	2016	Li et al.,	2016	Du et al.,	2014

Table 2

 2 A model that expresses a uni-variate time series Y t as a linear combination of past observations Y t-k and white noise t is referred to as an auto-regressive (AR) model and has the form

	Fault diagnostics			NA				NA			Bayesian network				NA				Motif and discord	analysis	Analyze extracted	rules, expert knowl-	edge	Expert knowledge
	Fault detection	CART, Kmean: peak	analysis GESD, DB-	SCAN; ANN: resid-	ual peak analysis		One class SVM			Linear regression	Similarity: PCA,	Mahalanobis dis-	tance; Sliding	window: 30min	snapshot of test data	comparing to whole	set of normal data	Symbolic aggre-	gate approximation	(SAX), motif and	discord extraction,	clustering	Association rules	Unreasonable gray	box parameter	indicates fault
	Pre-processing	Clustering with	CART, Kmean, DB-	SCAN; For each	cluster apply ANN	Steady state filter	(Rossii), select 8	variables	Steady state filter	(Rossii)			NA				NA	Fuzzy logic	NA
	Key	method		ANN,	Clustering		One class	SVM	Bayesian	network			Clustering				Clustering	Association	Rules	Gray box	modeling
	System Fault type	Lighting	and total Unknown	power	Chiller	(ASHRAE Mechanical	RP-1043)	Chiller	(ASHRAE Mechanical	RP-1043)		AHU Control, (ASHRAE mechanical RP-1312)			AHU Wrong (ASHRAE schedule RP-1312)	AHU Control	AHU, VAV Control
	Test	Data			M, M				C, M			C, M				C, M				-	-	-
	Training	Data			M, M				N, M			N, M				C, M				M, M	M, M	M, M
	Item	Capozzoli,	Lauro, and	Khan, 2015	Zhao,	Wang, and	Xiao, 2013	Zhao, Xiao,	and Wang,	2013		Li and Wen,	2014			Miller,	Nagy, and	Schlueter,	2015	Yu et al.,	2012	Gunay,	Shen, and	Yang, 2017

.2 -Summary of data driven AFDD studies, part 2.

  [START_REF] Dey | A Bayesian network approach to root cause diagnosis of process variations[END_REF] developed a process monitoring and diagnosis approach based on a Bayesian networks to identify the root cause of process variations. They used statistical method to identify the interaction between production faults and sensor metrics and to identify the Bayesian network structure. Cai, Liu, and Xie, 2016 built a Bayesian network with repetitive structure to represent large scale construction engineering systems, and realize online fault diagnosis. The network structure and parameters are defined based on expert knowledge.

	Machine operation fault detection: Sahin et al., 2007 developed a fault diagnosis system for
	airplane engines using Bayesian networks (BN). They used a particle swarm optimization
	method to learn the fault diagnosis network structure and parameters from data obtained
	from airplane engines during actual flights.
	Construction system fault detection:

[START_REF] Seixas | A Bayesian network decision model for supporting the diagnosis of dementia, Alzheimer's disease and mild cognitive impairment[END_REF]

proposed a Bayesian network decision model to support diagnosis of specific diseases. They designed the network structure based on current diagnostic criteria and inputs from physicians who are experts in this domain. The network parameters were estimated using a supervised learning algorithm from a data-set of real clinical cases.

Manufacture process fault detection:

Table 3 .

 3 1.

	Room	Controller	Radiator Room temperature
	High load	Disabled or Fault	Failed	Low
	High load	Disabled or Fault Normal	Low
	High load	Normal	Failed	Low
	High load	Normal	Normal	Low
	Normal load Disabled or Fault	Failed	Low
	Normal load Disabled or Fault Normal	Low
	Normal load	Normal	Failed	Low
	Normal load	Normal	Normal	Normal
	Zero load	Disabled or Fault	Failed	Normal
	Zero load	Disabled or Fault Normal	Normal
	Zero load	Normal	Failed	Normal
	Zero load	Normal	Normal	Normal

Table 3 .

 3 1 -Room temperature in condition of three components of the room radiator systemThe functioning of the radiator heating process is determined by the valve and heat exchanger characteristics, the hot water temperature, and the hot water pressure, as shown in Table3.2.

	Valve	Heat	Hot water	Hot water Radiator
		exchanger temperature pressure
	Fault	Fault	Low	Low	Failed
	Fault	Fault	Low	Normal	Failed
	Fault	Fault	Normal	Low	Failed
	Fault	Fault	Normal	Normal	Failed
	Fault	Normal	Low	Low	Failed
	Fault	Normal	Low	Normal	Failed
	Fault	Normal	Normal	Low	Failed
	Fault	Normal	Normal	Normal	Failed
	Normal	Fault	Low	Low	Failed
	Normal	Fault	Low	Normal	Failed
	Normal	Fault	Normal	Low	Failed
	Normal	Fault	Normal	Normal	Failed
	Normal	Normal	Low	Low	Failed
	Normal	Normal	Low	Normal	Failed
	Normal	Normal	Normal	Low	Failed
	Normal	Normal	Normal	Normal	Normal

Table 3 .

 3

2 -Root causes of radiator failure. Valve and heat exchanger fault refer to valve stuck close or heat exchanger blockage.

Table 3 .

 3 Table 3.3.Note that in this simulation model the building was very well insulated. Therefore in normal case in majority of the time the building doesn't have any heating load. 3 -Conditional probabilities of Room node in the room radiator system, obtained from simulation results as an example.

	Building enclosure	Weather	Room
			high	normal zero
			load	load	load
	normal, window close outdoor temperature lower than 0	0	0.50	0.50
	normal, window close outdoor temperature between 0 and 10	0	0.23	0.77
	normal, window close outdoor temperature between 10 and 20 0	0	1
	normal, window close outdoor temperature larger than 20	0	0	1
	fault, window open	outdoor temperature lower than 0	1	0	0
	fault, window open	outdoor temperature between 0 and 10	1	0	0
	fault, window open	outdoor temperature between 10 and 20 0.75	0.22	0.03
	fault, window open	outdoor temperature larger than 20	0	0.10	0.90

Table 3 . 4

 34 Table3.4. hot water temperature and pressure, which is the symptom of another HVAC subsystem, and therefore are caused by other faults. By connecting HVAC node and Energy Source node, the inter-dependency between HVAC sub-systems, or the causal relationship between faults in different HVAC sub-systems are represented in the Bayesian Network.The above mentioned logic represented by conditional probability is shown in Table3.5.

	System Controller HVAC	Controlled Variable
				Abnormal	Normal
	High	Fault	Fail	1	0
	High	Fault	Normal 1	0
	High	Normal	Fail	1	0
	High	Normal	Normal 1	0
	Normal Fault	Fail	1	0
	Normal Fault	Normal 1	0
	Normal Normal	Fail	1	0
	Normal Normal	Normal 0	1
	Zero	Fault	Fail	0	1
	Zero	Fault	Normal 0	1
	Zero	Normal	Fail	0	1
	Zero	Normal	Normal 0	1

-Conditional probabilities of Controlled Variable 2) HVAC and parent nodes HVAC failure is caused by abnormal HVAC Component Characteristics or Energy Source if available. Take room radiator system as an example: Abnormal HVAC Component Characteristics refer to valve stuck close and heat exchanger block. Abnormal Energy Source refers to ab-normal

Table 3

 3 Table3.11. In addition, the total heat demand is obtained from the state of the Room nodes. If all rooms have zero load, the total heat demand is zero.

	Building enclosure Outdoor air temperature Room
				High load Normal load Zero load
	Fault	Lower than 10 • C	0.85	0.15	0
	Fault	Between 10 • C and 20 • C	04	0.4	0.2
	Fault	Higher than 20 • C	0	0	1
	Normal	Lower than 10 • C	0	1	0
	Normal	Between 10 • C and 20 • C	0	0.5	0.5
	Normal	Higher than 20 • C	0	0	1
	Tank piping heat loss Total heat demand Hot water system
			High load Normal load Zero load
	Fault	Normal	0.85	0.15	0
	Fault	Zero	0		0.5	0.5
	Normal	Normal	0		1	0
	Normal	Zero	0		0	1
	Table 3.10 -Conditional probabilities of Hot Water System node in the room radiator system
	application.
	Piping resistance Piping	system
		High load Normal load
	Fault	1	0
	Normal	0	1
	Table 3.11 -Conditional probabilities of Piping System node in the room radiator system
	application.

.9 -Conditional probabilities of Room node in the room radiator system application.

Table 3 .

 3 12 -Fault diagnosis inference results. The objective of the inference process is to get an updated probability for all root fault nodes. Posted evidence is marked in gray. Root faults are marked in red. Most probable faults are in dark red color, and less probable faults are in light red color.

		Case1 Case2	Case3	Case4	Case5	Case6
	Symptom nodes
	Room radiator 01
	Room temperature	Low	Low	Low	Low	Low	Low
	Room radiator 02
	Room temperature			Normal Normal Normal Normal
	Room radiator 03
	Room temperature			Normal Normal Normal Normal
	Disturbance nodes
	Weather		Medium Medium Medium Medium Medium
	Virtual Evidence
	Room radiator 01
	Radiator fault					0.8	0.2
	Intermediate fault nodes
	Room radiator 01
	Radiator fault	0.86	0.86	0.70	0.79	0.94	0.48
	Room high load	0.14	0.13	0.19	0.27	0.13	0.56
	Hot water system
	Hot water temperature low 0.44	0.44	0.29	0.26	0.30	0.16
	Hot water system load high 0.15	0.15	0.10	0.13	0.15	0.08
	Hydraulic system
	Hot water pressure low	0.45	0.45	0.30	0.27	0.32	0.16
	Hydraulic system load high 0.17	0.17	0.11	0.14	0.17	0.09
	Root fault nodes
	Room radiator 01
	Controller fault	0.17	0.17	0.25	0	0	0
	Valve heat exchanger fault	0.17	0.17	0.25	0.36	0.43	0.22
	Building enclosure fault	0.16	0.20	0.25	0.33	0.20	0.59
	Hot water system
	Controller fault	0.17	0.17	0.11	0	0	0
	Boiler mechanical fault	0.17	0.17	0.11	0.14	0.17	0.09
	Tank piping heat loss fault	0.16	0.16	0.11	0.14	0.16	0.09
	Hydraulic system
	Controller fault	0.17	0.17	0.11	0	0	0
	Pump mechanical fault	0.17	0.17	0.11	0.14	0.17	0.09
	Piping resistance fault	0.17	0.17	0.11	0.14	0.17	0.09

Table 3 .

 3 13 and Table3.14 summarizes all the methods that we use to obtain evidences, and the required data. The Controlled Variable, Disturbances, and Controller evidence is rule-based hard evidence. HVAC process fault detection evidence is obtained through regression model or correlation distribution model, and is represented as virtual evidence.

		Controlled variable Disturbances	Controller
		3.3.1.1	3.3.1.2	3.3.1.3
	Node status Normal, Abnormal	Range1,...,RangeN Normal, Fault
	Data	-controlled variable -disturbances	-controlled variable
		-control set-point		-control enable
				-control set-point
				-control command
	Table 3.13 -Methods and required data for obtaining hard evidence
		Central HVAC		Room HVAC
		3.3.2.1		3.3.2.2
	Node status Normal, Fault		Normal, Failure
	Data	-control command -control command
		-power output		-controlled variable
		-*energy sources
	Method	regression model	correlation distribution model

Table 3

 3

.14 -Methods and required data for obtaining virtual evidence (* indicates optional data.)

Table 4 .

 4 2 -Overview of the evidence in the Green-O-Valley simulation case study.

		Virtual
		Evidence Evidence
	Symptom nodes
	Hot water supply temperature
	Chilled water supply temperature
	Supply water pressure (x4)
	AHU supply air temperature compared to heating set point (x3)	x
	AHU supply air temperature compared to cooling set point (x3)	x
	FCU room temperature compared to heating set point (x56)	x
	FCU room temperature compared to cooling set point (x56)	x
	Intermediate fault nodes
	AHU heating process fault (x3)	x
	AHU cooling process fault (x3)	x
	FCU heating process fault (x56)	x
	FCU cooling process fault (x56)	x
	Root fault nodes
	Boiler control	x
	Boiler heating process
	Hot water heating system
	Chiller control	x
	Chiller cooling process
	Chilled water cooling system
	Pump control (x4)	x
	Pump process (x4)
	Piping system (x4)
	AHU heating control (x3)	x
	AHU heating coil mechanical (x3)
	Supply air system heating (x3)
	AHU cooling control (x3)	x
	AHU cooling coil mechanical (x3)
	Supply air system cooling (x3)
	FCU heating control (x56)	x
	FCU fan and heating coil mechanical (x56)
	Room system heating (x56)
	FCU cooling control (x56)	x
	FCU fan cooling coil mechanical (x56)
	Room system cooling (x56)

Table 4

 4

	Time	Evidence	Root fault	Probability
	Scenario 1	AHU1 low	AHU1 heating control fault	0.26
		supply air	AHU1 heating coil mechanical fault	0.26
		temperature	AHU1 supply air system heating load high	0.26
			Hot water pump 1 control fault	0.15
			Hot water pump 1 pump process fault	0.15
			Hot water pump 1 piping system load high	0.15
			Boiler control fault	0.00
			Boiler heating process fault	0.00
			Hot water system load high	0.00
	Scenario 2	AHU1 low	AHU1 heating coil mechanical fault	0.36
		supply air	AHU1 supply air system heating load high	0.36
		temperature	Hot water pump 1 pump process fault	0.20
			Hot water pump 1 piping system load high	0.20
		AHU1 heating	Boiler heating process fault	0.00
		controller normal	Hot water system load high	0.00
			AHU1 heating control fault	0.00
			Boiler control fault	0.00
			Hot water pump 1 control fault	0.00
	Scenario 3	AHU1 low	AHU1 heating coil mechanical fault	0.50
		supply air	Hot water pump 1 pump process fault	0.29
		temperature	Hot water pump 1 piping system load high	0.29
			AHU1 supply air system heating load high	0.10
		AHU1 heating	Boiler heating process fault	0.00
		controller normal	Hot water system load high	0.00
			AHU1 heating control fault	0.00
		AHU1 heating	Boiler control fault	0.00
		99% chance fail	Hot water pump 1 control fault	0.00

.3 -Fault diagnosis results of fault 1: AHU1 heating valve stuck close Scenario 1: only symptom hard evidence

4.4.2 Fault 2. chilled water pump 2 (serving rooms) failure

	Time	Evidence	Root fault	Probability
	Scenario 1	High room	Chilled water pump 2 control fault	0.26
		temperature	Chilled water pump 2 pump process fault	0.26
		in 50 rooms	Chilled water pump 2 piping system load high	0.26
			Chiller control fault	0.14
			Chiller cooling process fault	0.14
			Chilled water system load high	0.14
			FCUs cooling control fault	0.10
			FCUs fan and cooling coil mechanical fault	0.10
			Room system cooling load high	0.10
	Scenario 2	High room	Chilled water pump 2 pump process fault	0.37
		temperature Chilled water pump 2 piping system load high	0.37
		in 50 rooms	Chiller cooling process fault	0.19
			Chilled water system load high	0.19
		Chilled water	FCUs fan and cooling coil mechanical fault	0.10
		pump control	Room system cooling load high	0.10
		normal	Chiller control fault	0.00
			Chilled water pump 2 control fault	0.00
			FCUs cooling control fault	0.00
	Table 4.4 -Fault diagnosis results of fault 2: rooms chilled water pump failure
	Scenario 1: only symptom hard evidence

Table 4 .

 4 7 -Confusion matrixThe accuracy (ACC) is proportion of correctly identified fault and normal cases among all test cases. The calculation results are shown in Table4.8.Since in this study the number of fault and normal cases are highly unbalanced, the overall accuracy is not fully representative of fault detection performance. Therefore we calculated sensitivity, precision, and F1 score for Fault 1 to 4. The calculation results are shown in Table 4.9. The results of other root fault nodes are NA and are not included in this table.

	ACC =	TP + TN TP + TN + FP + FN	(4.1)
	The sensitivity, or True Positive Rate (TPR) is the proportion of correctly detected faults among
	all fault cases.
	TPR =	TP TP + FN	(4.2)
	The precision, or Positive Predictive Value (PPV) is the proportion of correctly detected faults
	among all detected ones.
	PPV =	TP TP + FP	(4.3)

  • C to 40 • C. If the logged room temperature is 0 • C, it is a wrong value that needs to be removed. -Remove rapidly changed value based on min and max derivative settings. For example if the logged room temperature changes from 25 • C to 15 • C and then changes back in 10 seconds later, although the values are within normal range, the change is too rapid to be normal. It is most probably sensor noise. In this case the transient value 15 • C is removed.

  ). On the contrary, the low temperature in room 34 is most probably caused by FCU mechanical function fault such as valve stuck close (FCU34 mechanical function fault 99%).

		Evidence	Inference result
		probability probability
	Symptom nodes
	FCU20 room temperature low	1.00
	FCU34 room temperature low	1.00
	Intermediate fault nodes
	FCU20 heating process fault	0.20	0.22
	FCU34 heating process fault	0.99	0.99
	Hot water supply temperature low	0.00
	Hot water supply pressure low		0.00
	Root fault nodes
	FCU20 heating load high		0.80
	FCU20 controller fault or disabled	0.00
	FCU20 mechanical function fault		0.22
	FCU34 heating load high		0.11
	FCU34 controller fault or disabled	0.00
	FCU34 mechanical function fault		0.99
	Heat pump2 heating load high		0.00
	Heat pump2 control command off		0.05
	Heat pump2 mechanical function fault		0.03
	Pump2 hydraulic load high		0.10
	Pump2 control command off	0.00
	Pump2 mechanical function fault		0.10
	Table 5.4 -Fault diagnosis inference results, Porte-de-Retz building, 02/03/2016-10AM

In this specific case, although room 20 and room 34 both have low temperature, based on the integration of FCU heating process evidence (correlation analysis), the fault diagnosis Bayesian network is able to correctly identify 'Fault a' only in room 34.

RT2012 is the sustainable building design standard in France.

Energy performance of buildings directive (EPBD) gives guidance to European Union member countries to improve building energy performance.

LEED is a well recognized commercial building performance rating system from the USA.

https://www.project-haystack.org/

Application of the fault diagnosis network concept

In this section we take the boiler-pump-radiator system as an example to demonstrate how the fault diagnosis network concept is applied to building level fault diagnosis. The belief updating process is realized using the SMILE reasoning engine (Pysmile) through its Python wrapper. [START_REF] Tungkasthan | Automatically building diagnostic bayesian networks from on-line data sources and the smile web-based interface[END_REF]

Structure

The HVAC system is composed of one boiler, one hot water pump and three radiators serving three rooms individually. The boiler and the pump have on-off control, and the radiator has close loop regulating control. The available data are set-points, enable-signals, and command of the controllers, the room temperatures, and the outdoor air temperature. The hot water supply temperature and pressure are not measured. The steps for constructing the fault diagnostic Bayesian Network are described below:

Step1. Identify HVAC subsystems and the energy chain based on system topology metadata. In this application, three room radiator sub-systems are served by a hot water subsystem and a hydraulic sub-system.

Step2. Identify the components of each sub-system: Controlled Variable, Controller, HVAC, and Recipient System, refer to the examples of specific HVAC sub-systems shown in section 3.2.3. Make links between energy sources and energy consumers. In this application, links are from Hot Water Temperature of the hot water system and Hot Water Pressure of the hydraulic system to Radiator of the room radiator system.

Step3. Mark available input/output data for each sub-system components. The enable-Chapter 4

Validation with simulation data

This chapter presents the results obtained by the fault diagnosis Bayesian network method with simulated dynamic building operation data. The scale and complexity of the simulated building is comparable to real office buildings, in order to test the usability of the new method. In addition to normal operation, four specific faults are created in the simulation to test the performance of the fault diagnosis Bayesian network. The results show that the method is able to easily handle large numbers of equipment, and to correctly identify root causes with given evidence. The accuracy of the root fault identification is related to the accuracy of the evidence.

Description of simulation data

The building simulation data is generated by a dynamic real time thermal model implemented in IDA-ICE, including building envelope, HVAC system, and associated control loops. This model is a digital twin of one building (38TEC-T11) of Schneider Electric Green-OValley project in Grenoble. The parameters of the building model is given in Appendix A. In our study, we simplified the model by removing some rooms and replacing the heat pump models with simple boiler and chiller models.

The simulation period spans one year from 1 Jan 2018 to 31 Dec 2018. Four faults were implemented in the simulation:

1. AHU1 heating valve stuck close: 9 Jan and 10 Jan Note that as opposed to the fault 1 to 3, fault 4 is present in the whole data-set, but only visible when the cooling load is too high.

The dynamic simulation results are used to obtain evidence for the network as explained in section 3.3, and to test if the faults will be correctly diagnosed.

Implementation

Structure

The simulated building and HVAC system have 56 rooms equipped with FCUs (Fan Coil Units), and 3 AHUs (Air Handling Units). One boiler and one chiller serve as heating and cooling energy source. Two hot water pumps and two chilled water pumps serve AHU and rooms respectively. The boiler, chiller, pumps, and AHU fan have on-off control. The AHU heating and cooling coil valves are modulated by PI controllers to maintain supply air temperature at set point. The room heating and cooling coil valves are modulated to maintain room temperature at set point. The system topology, the system flow chart, and the fault diagnosis network are shown in Figures 4.1,4.2,and 4.3.

The conditional probabilities of Recipient System nodes ('hot water system', 'chilled water system', 'piping system', 'supply air system', 'room thermal system') need to be set up based on quantified expert knowledge. For example, the 'room thermal system' state is related to weather conditions and building envelope. We can have outside temperature and window open/close state as parent nodes, and the conditional probabilities are based on building thermal load simulation (as in section 3.2.1). The method of defining these parameters is only partially covered in our study. It may be extended as a separate topic for future research. For the 'whole building' use cases with simulation data (chapter 4) and real building data (chapter 5), we limit the scope of the Bayesian network model up to the Recipient System nodes. The parents nodes of Recipient System nodes are not included.

The available data are marked in shade in the system flow chart

Parameters

Fault Normal Boiler heating process 0.1 0.9 Boiler control 0.1 0.9 Chiller cooling process 0.1 0.9 Chiller control 0.1 0.9 Pump hydraulic process 0.1 0.9 Pump control 0.1 0.9 AHU heating coil mechanical 0.1 0.9 AHU heating control 0.1 0.9 AHU cooling coil mechanical 0.1 0.9 AHU cooling control 0.1 0.9 FCU fan and heating coil mechanical 0.1 0.9 FCU heating control 0.1 0.9 FCU fan and cooling coil mechanical 0.1 0.9 FCU cooling control 0.1 0.9 High load Normal load Hot water heating system 0.1 0.9 Chilled water cooling system 0.1 0.9 Piping hydraulic system 0.1 0.9 AHU air supply system 0.1 0.9 High load Normal load Zero load The symptom is high room temperature in room 01, which may be caused by FCU faults or chilled water system (chiller, water pump 2) faults. Chilled water system faults are eliminated because the other FCUs and AHUs served by the same chiller and pump are in normal state. FCU controller fault, mechanical fault (cooling coil, valve, or fan), and high room cooling load are all possible with same probabilities.

Scenario 2: include controller fault detection hard evidence

The FCU cooling control command in room1 is maximum with a value of 100% which is the normal reaction expected from the controller. Therefore the controller fault is eliminated by the Bayesian Network, and the probability of other faults becomes higher.

Scenario 3: include HVAC fault detection virtual evidence FCU cooling process fault probability is obtained from a correlation distribution model as explained in section 4.3.4. In room 01, the cooling process fault probability is computed and its value is over 80%. Based on this virtual evidence, the network is able to identify that the root fault in room 1 is FCU fan and cooling coil mechanical fault, which is correct. Within 20 hours of AHU1 heating valve fault, 16 hours are correctly identified, 2 hours are incorrectly identified as Supply air system heating load high.

Fault 2. rooms chilled water pump failure

Since there is no evidence to differentiate 'pump process fault' and 'piping system load high' (that may be caused by piping leakage), these two root faults appear to be equally possible.

All 20 hours of chilled water pump failure fault are correctly identified.

Fault 3. room1 cooling valve stuck close

Within 50 hours of FCU1 cooling valve fault, 49 hours are correctly identified, and 1 hour is missed. However 118 normal hours are incorrectly identified as fault hours, due to the inaccuracy of room equipment level fault detection. More discussion is included in section 4.3.4 and section 6.2.

Fault 4. room 4, 19, and 24 FCU cooling coil under dimension

In the simulation, room 4, 19 and 24 FCU cooling coil are under dimension, which causes room temperature higher than the set point. Within 2020 hours of high cooling load fault, 1543 hours are correctly identified, 477 hours are missed. 54 normal hours are incorrectly identified as fault, due to the inaccuracy of room equipment level fault detection. More discussion is included in section 4.3.4.

The overall results show that the method is able to easily handle large numbers of equip-

Green-O-Vally building: manually created fault in GreenOValley building

In GreenOValley building, we had the chance to manually create faults with AHU to test the fault detection performance.

Test of Porte-de-Retz building

The Bayesian network fault diagnostics method is applied to the Porte-de-Retz building.

First, the HVAC system topology and operation mode information are collected (5.2.1).

Based on this, the Bayesian network is implemented (5.2.2). Evidence is created from operation data and used for fault diagnostics (5.2.3). In the end, the fault diagnostics results are presented (5.2.4). The topology of the HVAC system in the 'Port-de-Retz' building is illustrated in Figure 5.5.

HVAC system topology and operation mode

The HVAC system switches between heating and cooling mode based on outside air temperature. Two heat pumps provide hot water or chilled water to the whole building. Heat pump 1 serves two AHUs with pump 1, the FCUs in the north area of the first floor with pump 2, and the entrance floor heating with pump 3. Heat pump 2 serves the FCUs in the south area of the first floor and the whole area of the second floor.

The heat pumps and the circulation pumps have on-off control based on the operation hour of the building. The heat pump North is connected to three secondary circulation pumps.

The heat pump South only has built-in primary circulation pump. The AHUs have one coil to heat or cool the supply air, the valve is modulated to maintain the supply air temperature at the set point. Similarly, the FCUs in rooms have one coil to heat or cool the room, the valve is modulated to maintain the room temperature at the set point. The default room set point is 21 • C for heating and 26 • C for cooling. The occupants in the office can adjust the set point to 3 • C higher or lower than the default value.

Implementation of fault diagnostics network

Structure

The fault diagnosis network focuses on the FCUs in rooms, and associated heat pumps and distribution pumps. We follow the general approach described in section 3.2.2. Each equipment is represented by two sub-systems, representing heating function and cooling function respectively. When the system is in heating mode, the cooling sub-system is disabled, and vise versa. The fault diagnosis network is shown in Figure 5.6.

Parameters

The conditional probabilities are defined by logic as described in 3.2.2.3. The prior probabilities also follow the proposition in 3.2.2.3; they are listed in

Evidence

The evidence nodes are marked in gray in the network diagram Figure 5.6. Dark gray indicates hard evidence, and light gray indicates soft evidence.

Symptom nodes

The state of the Symptom nodes are hard evidence obtained by comparing the Controlled Variables to the set points, as explained in section 3.3.1.1. All set points are listed in Table 5.2.

For room temperatures, we choose to use fixed set points instead of the set points given by the HMI. When a control fault is identified, it can be outstanding set point or wrong control command. 5.2 -Set points of controlled variables, Porte-de-Retz building

Controlled variable Set point

Control nodes

The state of the Control nodes are hard evidence obtained from the control command data, as explained in section 3.3.1.3. 'Heat pump heating control' and 'Heat pump cooling control' on/off states are given by the heat pump heating / cooling mode data. 'Pump control' on/off states are directly read from data as well. 'FCU heating control' and 'FCU cooling control' disable/fault/off states are computed from the control commands, controlled variables, and set point.

HVAC process nodes

The probability of states of the HVAC node 'FCU heating process' and 'FCU cooling process' are obtained from the time series analysis as explained in the following.

Step1. correlation calculation

In Porte-de-Retz building, room heating control command and cooling control command are associated with the same valve of the FCU coil. In heating mode, the room temperature rises when the valve opens, therefore the correlation between room temperature deviation and control command should be between 0 and 1. In cooling mode, the room temperature drops when the valve opens, therefore the correlation should be between -1 and 0. In reality, because of noise and irregular disturbances, the correlation in different rooms from different time periods is a random variable with certain probability distribution.

The correlations between room temperature deviation and control command in heating mode and cooling mode in each room and every 6-hours period are calculated respectively. The correlation results are shown in the heat map

Step3. Calculate fault probability

Based on the cumulative distribution function obtained from the Gaussian Mixture model, we can calculate the probability of the three modes given a specific correlation.

As shown in Table 5.3, in normal case the detected correlation mode should go with the actual control mode. Otherwise it indicates that faults occur.

Building level diagnosis results

Based on the Bayesian network, we wrote a program to display all abnormal Symptoms for a given time, and automatically trace the root cause of each abnormal Symptom. In this section we will now investigate the time period shown in 5.1.4.1 to verify if the right root faults are identified by the Bayesian Network.

Parameters

The conditional probabilities are defined by logic as described in 3.2.2.3. The prior probabilities are listed in

Evidences

The evidence nodes are marked in gray in the network diagram Figure 5.17. Dark gray indicates hard evidence, and light gray indicates virtual evidence.

Symptom nodes

The state of the Symptom nodes are obtained by comparing the Controlled Variables to the set points. All set points are listed in Table 5.6. For room temperatures, we choose to use definitive set points instead of the set points given by the HMI. When a control fault is identified, it can be an outstanding set point or a wrong control command. 5.6 -Set points of controlled variables, GreenOValley building

Controlled variable Set point

Control nodes

The state of the Control hard evidence nodes are obtained from the control command data as explained in 3.3.1.3. 'Heat pump heating control' and 'Heat pump cooling control' on/off

3) Obtaining evidences from data. In this study, symptom evidences and disturbance evidences are directly obtained from data, rule based fault detection results of controllers are integrated as hard evidences, and data driven fault detection results of HVAC processes are integrated as virtual evidences. In practice the fault detection evidences can be replaced by third party equipment fault detection results. It allows the method to integrate different fault detection solutions.

4) Interactive workflow. The method doesn't provide a definitive conclusion on the existing faults. The results are the probabilities of all possible faults. Based on this information, the user can start with field investigation of the most possible fault. If it appears to be normal, the user can set the corresponding node in the Bayesian network to 'normal', and then the new most possible fault will be calculated. This interactive work flow allows the user to add their own judgment as additional information to the diagnosis solution at any time.

A.1.2.1 Wall properties

The heat transfer coefficient (U-value) of walls, roofs, and floors are giving in

A.1.2.5 Infiltration

According to the Green O Valley project document, the air tightness level fulfills the French regulation: 0,95 m3/h/m2 at a pressure difference of 4 Pa.

A.1.4 HVAC system: Heating and cooling generation

Heating and cooling are supplied to the building with the help of two heat pumps which deliver heat and cold at the same time.

-Cooling power: 328kW each -Heating power: 367kW each -Electrical power: 74kW each -Temperature 7°C/13°C -Condenser 4kW -Evaporator 4kW -Each heat pumps have 4 compressors Summer mode: if Text > 17°C, the 2-ways valve V2 is controlled to try to maintain a 20°C constant temperature return (S1 sensor).

Winter mode: if Text < 15°C, the 2-ways valve V1 is controlled to try to maintain a 13°C constant temperature return (S2 sensor).

A.1.5 HVAC system: Hot water and chilled water distribution

The hot water and chilled water circuit supply the following 4 groups of zones with constant water temperature of 45°C and 7°C respectively:

-Southern fan coils -Northern and center fan coils -AHU kitchen and restaurant (5,7,9,10) -AHU offices (1, 2, 3, 4, 6, 6R)

A.1.6 HVAC system: Ventilation system

A.1.7 HVAC system: Room heating and cooling device

The rooms heating and cooling are provided by fan coil units (FCU) equipped with room controllers. The FCUs have heating and cooling coil, fan, and air damper. Besides temperature sensors, valve and damper actuators, the room controllers are also connected with room CO2 sensors and occupancy sensors.

A.2 Porte de Retz building

A.2.1 Building plan

The Port de Retz building is located in Nante, France. It is an office building with 2 floors, as shown in

A.2.3 HVAC system: Overview

The topology of the HVAC system in the 'Port-de-Retz' building is illustrated in Figure A.9.

The HVAC system switches between heating and cooling mode based on outside air temperature. Two heat pumps provide hot water or chilled water to the whole building. Heat pump 1 serves two AHUs with pump 1, the FCUs in the north area of the first floor with pump 2, and the entrance floor heating with pump 3. Heat pump 2 serves the FCUs in the south area of the first floor and the whole area of the second floor.