# Advancing Building Fault Diagnosis Using the Concept of Contextual and Heterogeneous Test

Mahendra Singh, Nguyen Trung Kien, Houda Najeh, Stéphane Ploix, Antoine Caucheteux

► To cite this version:

Mahendra Singh, Nguyen Trung Kien, Houda Najeh, Stéphane Ploix, Antoine Caucheteux. Advancing Building Fault Diagnosis Using the Concept of Contextual and Heterogeneous Test. Energies, 2019, 12, 10.3390/en12132510. [hal-04967618](https://hal.science/hal-04967618v1)

HAL Id: hal-04967618

https://hal.science/hal-04967618v1

Submitted on 26 Feb 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Article

# Advancing Building Fault Diagnosis Using the Concept of Contextual and Heterogeneous Test

Mahendra Singh <fnref n="1" />,* , Nguyen Trung Kien <fnref n="1" />, Houda Najeh <fnref n="1" />, Stéphane Ploix <fnref n="1" />
and Antoine Caucheteux <fnref n="2" />

Received: 10 April 2019; Accepted: 24 June 2019; Published: 29 June 2019

<figure><img src="image_2.png" /></figure>

check for
updates

**Abstract:** Fault diagnosis and maintenance of a whole-building system is a complex task to perform. A wide range of available building fault detection and diagnosis (FDD) tools are only capable of performing fault detection using behavioral constraints analysis. However, the validity of the detected symptom is always questionable. In this work, we introduce the concept of the contextual test with validity constraints, in the context of building fault diagnostics. Thanks to a common formalization of the proposed heterogeneous tests, rule-, range-, and model-based tests can be combined in the same diagnostic analysis that reduces the whole-building modeling effort. The proposed methodology comprises the minimum diagnostic explanation feature that can significantly improve the knowledge of the building facility manager. A bridge diagnosis approach is used to describe the multiple fault scenarios. The proposed methodology is validated on an experimental building called the center for studies and design of prototypes (CECP) building located in Angers, France.

**Keywords:** buildings; fault diagnosis; bridge diagnosis; fault detection and isolation (FDI) and logical diagnosis (DX); model validity; consistency and conflict; sensors; contextual test; logical diagnosis; model-based diagnosis

## 1. Introduction

Customarily, commercial and office buildings are equipped with building automation system (BAS) and supervisory controllers. Controller-based actions play an important role in achieving the desired level of indoor comfort after post-commissioning of existing building energy management systems (BEMS). Buildings are going to be more complex due to continuous integration of substantial amount of emerging technologies and higher user expectations [1]. In this context, technical malfunctions or unplanned contexts can have a huge impact on building operation and occupant comfort. To make a resilient building management system, it is important to identify the severity, cause, and type of each fault.

Building control alone is not enough to decide maintenance issues. Existing building management either suggests long planning or corrects the building anomalies by applying rule-based controller actions. Another available solution is set-point tracking, without knowing building inconsistencies [2]. However, in various situations, building operations enter conflicting situations when pre-defined corrective actions or set-point tracking is not enough to maintain the desired building performance. Tracking the set-point or following the rule-based controller actions could result in a poor energy building performance.

Therefore, building fault detection and diagnosis (FDD) plays an important role in managing the whole-building performance. There are several methods already proposed to tackle faulty operation of the building system. Moreover, a large number of methods rely on being model-based or data-driven.

<footnote n="1">¹ Laboratoire G-SCOP, UMR 5272, 46 Avenue Félix Viallet, 38031 Grenoble, France</footnote>

<footnote n="2">² Cerema Ouest, 23 Avenue de l'Amiral Chauvin, BP 20069-49136 Les Ponts-de- Cé cedex, Angers, France</footnote>

<footnote>* Correspondence: mahendra.singh@outlook.fr</footnote>
In reality, it is difficult to set up a model taking into account all local contexts. On the other hand, data-driven models are challenged by the validity of sensor data and measurements. The present work discusses the different challenges and limitations of existing fault diagnosis methodologies. This paper presents an innovative whole-building diagnostic framework that addresses different challenges such as building system complexity and contextual validity of data.

<figure><img src="image_3.png" /><figcaption>**Figure 1.** Enumerated scheme of the proposed building diagnosis framework.</figcaption></figure>

The above figure illustrates the various steps of the proposed methodology. The first phase of the proposed framework is the designing of tests, (Figure 1). It includes analyzing the living zone to identify different building components and sub-systems along with associated variables. Furthermore, this step ends up with a deduced signature table after removing non-detectable components and merging non-discriminable ones. However, the second phase of the proposed framework is the run phase that counts collected sensor data and heterogeneous tests. The outcome of run phase gives a set of minimum possible diagnosis taking into account BRIDGE (FDI+DX) diagnosis analysis. Indeed, in the rest of the paper these two phases are narrated with the help of theoretical and practical evidence.

The concept of the contextual and heterogeneous tests is introduced in Section 3. These tests support the validity of diagnosed fault and are easy to model. Furthermore, a BRIDGE approach, coming from logical diagnosis, has been adopted to analyze a test in Section 5. Finally, the paper summarizes a case study to support the proposed tests and diagnosis methodology.

## 2. Challenges and Issues

Over recent years, FDD has become an appealing area of research for building researchers. Various methodologies and tools have been developed to identify the faults in buildings to track the whole-building performance. Plenty of published research and survey papers are available to classify building diagnostic techniques [3–5]. Recently, building faults and failures have been
covered at more granular level with an impact analysis in the terms of energy consumption and financial consequences [6,7]. Hybrid diagnosis approaches have shown an improved result over the conventional model-based diagnosis approaches [8,9].

In general, all the major approaches that have been used for building diagnoses are quantitative (model-based) or qualitative (rule-based). Model-based methods rely on an analytical model, derived from a physical relation. In connection with buildings, it is impossible to develop a complete physical model accurately matching the reality for a whole-building system. The various phenomena such as heat transfer from facade and/or unplanned occupancy are challenging issues to model. In [10], the whole-building-modeling issue was addressed by the model-based whole-building energy-plus model. Model-based diagnosis relying on behavioral constraints are assumed to be true in all circumstances. However, universally valid behavioral models i.e., valid whatever the context, are difficult to set up. On the other hand, qualitative models are not enough to cover all the possible actions by following rules. A systematic approach for test generations ends up with a huge number of tests and is difficult to handle [11]. In fact, tests derived from rules are challenged by their *validity*. For instance, testing indoor temperature without validating door or window position might lead to a false alarm.

In buildings, a huge amount of metered data is available from sensor measurement, and time-series-based statistical analysis could generate the fault pattern of particular appliances showing abnormal behavior. However, this method is challenged by a building's complexity and interconnecting devices. Data only reveals that some sensors or actuators are behaving properly. On the other hand, an occupant feedback-based diagnosis system is expensive to deploy in buildings due to a lack of man-machine-language interface [12,13]. The delicacy of these methods is to support an easy detection and giving the first impression about faults. While accounting the whole-building performance, different faults can be categorized into four major categories—an inefficient or poor performance of building appliances, physical failures, wrongly programmed building management system and equipment, and finally, unplanned situations [5].

The key challenges in building diagnosis are summarized below:

* modeling a complete building fault model integrated with all building components is too complicated a job to model

* pure rule-based approaches alone are not actually able to cover all possible contexts.

* diagnosis of conflicting set-point and wrongly configured building equipment is very complicated

* occurrence of combined fault is not given enough attention

Another major challenge in building diagnosis is *explainability* of a diagnosed result. Occupants or maintenance experts are willing to get involved in the diagnostic process and are interested in the *Know-how* process. This step could ease the diagnosis experience and maintenance strategy. In the present approach, the concept of minimum *Diagnostic Explanation Feature* (DEAF) has been adopted to develop all possible explanations for building anomalies.

### 3. Problem Statement

Current work highlights the following key challenges in building fault diagnoses:

* limitation of the number of behavioral constraints in model-based diagnoses

* limitation of testing whole-building systems using rule- and pure model-based tests

* combining faults coming from different building sub-systems

The following subsections explain these issues and proposed methodology in detail.
### 3.1. Need for Testing in Specific Context

Context modeling is a well-established research field in computer science. There are various terminologies and definitions have been proposed to explain the meaning of context. In [14] Dey, context is defined as:

> "any information that can be used to characterize the situation of an entity, where an entity can be a person, place, or physical or computational object."

In buildings, such concepts are still at an immature level. However, a few interesting works are present in the literature. Fazenda [15] discusses the various aspects of context-based reasoning in smart buildings. In [16], the authors proposed an additional level, i.e., **"Context anomaly"** for smart home anomaly management. In the domain of the fault diagnosis, a symptom is defined as an abnormal measurable change in the behavior of a system i.e., an indication of fault. The conventional model or rule-based behavioral tests are used only to generate symptoms. These models appear in the behavioral constraints (Definition 1) and it is assumed that a behavioral test could be applied to any situation without taking into account different contexts [17].

However, a model valid for all contexts is difficult to set up and the validity of a test result is always questionable. There are various alarms that might trigger due to use of building system in the wrong context, for example:

1. An automated building with blind control that optimizes daylight use and saves energy consumption from artificial lights. In meantime, solar gain might increase the indoor temperature and force the heating, ventilation, and air conditioning (HVAC) system to cool down the space. This could be an issue for a building analytics team, and they might report over-consumption or abnormal behavior of a building system. However, this is a case of missing contextual validity [16].

2. Similarly, an alarm showing poor thermal comfort could be initially addressed by analyzing the local context such as occupancy level, door or window positions, activity level, and interaction with an adjacent room or neighboring building, etc.

3. Diagnosis reasoning must differ in different scenarios, e.g., fault detection and diagnosis approaches should be different for normal working days and a vacation period.

**Definition 1.** Let $X_{(t,t+h)}$ be a set of variables covering a time horizon h and $K(X_{(t,t+h)})$ be a set of constraints with $K(X_{(t,t+h)}) \in D_k$ if satisfied, where $D_k$ is a bound domain. A behavioral constraint set modeling the normal behavior (ok) is defined as:

$$ ok \leftrightarrow \forall X_{(t,t+h)}, K(X_{(t,t+h)}) \in D_K \text{ or} $$

$$ \exists X_{(t,t+h)}, K(X_{(t,t+h)}) \notin D_K \leftrightarrow \neg ok $$

where $\neg$ is negation that implies $\neg ok = \text{Not ok}$.

In contrast, the proposed contextual tests are more specific and offer an easy way to test the whole-building system considering various non-modeled events. The contextual test combining different events is based on validity constraints (Definition 2) for a test. In the field of intelligent diagnosis, the concept of validity constraint was initially introduced in [18,19].

In recent developments, energy management schemes are extended to the city and urban scale [20]. Various upper and lower level energy management schemes were proposed [21,22]. Often, energy management schemes do not consider the component-level analysis in case of a discrepancy between expected and actual performance. In this sense, the proposed context-aware diagnostic framework could be easily integrated as a middle layer with existing energy management services to react over undesired situations.
**Definition 2.** Let’s introduce another set of constraints $V(X_{(t,t+h)}) \in D_v$ where $D_v$ is a bound domain, to define the validity of a behavioral constraint set ($X$ is assumed to be a superset of the variables appearing either in behavioral or in validity constraint sets, i.e., some variables might not appear in both constraint sets). A behavioral constraint set modeling the normal behavior under validity conditions is defined as:

$$ \begin{array}{l} \forall X_{(t,t+h)}, K(X_{(t,t+h)}) \in D_k \leftrightarrow ok \wedge (X_{(t,t+h)}, V(X_{(t,t+h)}) \in D_v) \text{ or, equivalently} \\ \exists X_{(t,t+h)}, K(X_{(t,t+h)}) \notin D_k \leftrightarrow \neg ok \vee (\exists X_{(t,t+h)}, V(X_{(t,t+h)}) \notin D_v) \text{ or} \\ (\exists X_{(t,t+h)}, K(X_{(t,t+h)}) \notin D_k) \wedge (\forall X_{(t,t+h)}, V(X_{(t,t+h)}) \in D_v) \leftrightarrow \neg ok \end{array} $$

In a more generic explanation, validity is defined as a set of constraints that need to be satisfied for the related behavioral test. Testing a building system without checking the linked validity constraints could lead to an erroneous test result.

A practical example of a contextual test considering the building thermal performance is given below. Consider a behavioral model for the building (Figure 2) is estimating and testing the indoor temperature with a behavioral constraint, i.e., estimated temperature $T_{est}$ from model lies between the maximum temperature ($T_{max}$) and minimum temperature ($T_{min}$).

<figure><img src="image_4.png" /><figcaption>Figure 2. Behavioral and Contextual test for diagnosis.</figcaption></figure>

However, no validity constraints are integrated with the test. Figure 2 illustrates the significance of the contextual test along with an example of an invalid event i.e., opened window. In this case, the following validity constraints need to be combined with behavioral constraints:

* Testing indoor temperature without verifying occupancy level might lead to a false alarm

* The door and window position need to be verified because these inputs are not easy to model

* Similarly, outdoor weather condition needs to be verified

In conclusion, validity is another kind of knowledge about the behavior. For a valid diagnosis analysis, each test needs to satisfy the validity and behavioral constraints simultaneously.

Table 1 summarizes the way to combine both constraints, where $K$ and $V$ are behavioral and validity constraint sets. “No conclusion” test results or symptoms are not interesting for diagnosis purposes and must be discarded from the diagnostic analysis.
<table><caption>**Table 1.** Table of validity from Definition 2.</caption><thead><tr><td>Behavioral Constraint (K)</td><td>Validity Constraint (V)</td><td>Conclusion</td></tr></thead><tbody><tr><td>satisfied</td><td>satisfied</td><td>data consistent with normal behavior</td></tr><tr><td>satisfied</td><td>unsatisfied</td><td>no conclusion</td></tr><tr><td>unsatisfied</td><td>satisfied</td><td>abnormality</td></tr><tr><td>unsatisfied</td><td>unsatisfied</td><td>no conclusion</td></tr></tbody></table>

## 3.2. Need for Heterogeneous Tests

Modeling from physics of a whole-building systems including building components requires a huge effort and there are various practical difficulties. For instance, there are several variables shared among the building sub-systems and these are difficult to model because of their intricate relationships. Using only pure model-based approaches, as in FDD, is a challenging job. To deal with building complexity issue, a unified approach to manage heterogeneous tests for diagnostic analysis is introduced in this work. In general, a test (Definition 3) is a process yielding a symptom and possible explanations. Heterogeneous tests are the combination of the rule-, range-, and model-based tests, derived from the same meta-knowledge [17].

Range-based (Definition 4) tests are designed with the help of an upper and lower limit of tested variable. Diagnosis process starts when an observation violates the pre-defined threshold. However, in a building system, certain performance indicators do not require explicit ranges for diagnostic analysis. For instance, a ventilation fan must be consuming less power than the maximum rating. Such variables could be tested with the help of a rule-based test (Definition 5).

**Definition 3.** A detection test is defined by:

1. $K(X_{(t,t+h)}) \in D_k$

2. $V(X_{(t,t+h)}) \in D_v$

3. A set of possible explanations in terms of component or item states such as: $Expl = \neg ok(item_1) \land \neg ok(item_2) \land \dots$

4. A batch of data $X_{(t,t+h)}$ related to the set of variables $X = \{x_1, x_2, \dots\}$ covering a time period $(t, t+h)$. It satisfies:

$$ (\exists X_{(t,t+h)}, K(X_{(t,t+h)}) \notin D_k) \land (\forall X_{(t,t+h)}, V(X_{(t,t+h)}) \in D_v) \leftrightarrow Expl $$

**Definition 4.** Range-based if $K(X_{(t,t+h)}) \in D_k$ is made of intervals belonging to checks. It is a simple test derived with the help of upper and lower bounds.

**Definition 5.** Rule-based if $K(X_{(t,t+h)}) \in D_k$ is made of "if...then...else... implications".

**Definition 6.** Model-based if $K(X_{(t,t+h)}) \in D_k$ is made of modeling equations.

Expert knowledge [23] helps to discover all possible explanations. Notwithstanding, rule-based tests such as expert knowledge are not enough to cover all the possible discrepancies with the set of rules. Moreover, these tests are limited to certain rules and unable to check the building performance at zonal level. A building system encompasses several zones with different zonal properties. To develop a global diagnostic approach, the present approach is extended to a low-level model-based zonal test (Definition 6). These models include all major easy-to-model building sub-systems, such as ventilation, heating system, appliances, etc.

## 4. Different Kinds of Contextual Tests

This section deals with the examples of different types of test and how it is possible to combine these tests for a diagnostic analysis.
## 4.1. Test1 (Indoor Temperature Test Leading to the Set-Point Deviation), Range-Based

Here is an example of a range-based test that verifies the indoor temperature ($T_{in}$) range in a building system. Test function ($T_{in}$) generates test results for the deviation of indoor thermal building performance. Possible fault explanations might include sensor-level fault, but sensor-level faults are excluded and considered to be non-faulty i.e., ok-state only. For instance: ok sensor : indoor temperature ($T_{in}$)) → obs($T_{in}$) = $T_{in}$ where ok signifies the non-faulty behavior of temperature sensor and obs stands for an observed value. Possible fault explanations for this test combine all the major components that potentially affect a building’s thermal performance. For example, unplanned occupancy ∨ broken radiator could be responsible for the poor thermal performance, where ∨ is logical OR. Indoor temperature test function is given as:

$$ \textbf{Test1}(T_{in}) = \begin{cases} \text{inconsistent} & \text{if } (\neg(K(X_{(t,t+h)} \in D_k) \land V(X_{(t,t+h)} \in D_v)) \\ \text{consistent} & \text{if } (K(X_{(t,t+h)} \in D_k) \land V(X_{(t,t+h)} \in D_v)) \\ \text{no conclusion} & \text{otherwise} \end{cases} \quad (1) $$

where

$$ K(X_{(t,t+h)} \in D_k) \rightarrow (T_{in}^{min} \leq obs(T_{in})) \land (obs(T_{in}) \leq T_{in}^{max}) $$

$$ V(X_{(t,t+h)} \in D_v) \rightarrow (obs(occupancy) \in (occupancy_{min}, occupancy_{max}) $$

$$ \land (T_{out} \in (T_{min}^{\text{weather predicted}}, T_{max}^{\text{weather predicted}}) $$

$$ \land (obs(\text{door or window position}) \in (\text{close}, \text{open}) $$

**Possible fault explanations for Test1:**

open door or window ∨ broken or pierced ventilation pipes ∨ clogged filter ∨ unplanned appliances ∨ broken boiler ∨ faulty duct ∨ unplanned occupancy ∨ broken radiator ∨ broken thermostat ∨ faulty supply or return fan.

**Required sensors for validity:**

* obs(occupancy) : estimated based on power consumption and indoor CO₂ level

* obs($T_{out}$) : outdoor sensor reading

* obs(door or window position) : contact sensor

**Required sensors for behavior:**

* obs($T_{in}$) : indoor temperature sensor reading

* obs(occupancy) : estimated based on power consumption and indoor CO₂ level

* obs($T_{out}$) : outdoor sensor reading

* obs(door or window position) : contact sensor

**Assumption:**

Sensors used for behavioral and validity constraints are in ok state.

## 4.2. Test2 (Airflow), Rule-Based

This test analyzes the measured airflow from ($Q_{air}^{measured}$) a ventilation system. A minimum required airflow ($Q_{air}^{min}$) rate is set by the building management system. The test evaluates the mismatch
between the measured and minimum required airflow. Possible explanations are derived from "if . . . then . . . else . . . implication" and help to establish a link between the test and faulty components.

$$
\textbf{Test2}(\text{obs}(Q_{\text{air}})) = \begin{cases} \text{inconsistent} & \text{if } (\neg(K(X_{(t,t+h)} \in D_k) \land V(X_{(t,t+h)} \in D_v)) \\ \text{consistent} & \text{if } ((K(X_{(t,t+h)} \in D_k) \land V(X_{(t,t+h)} \in D_v)) \\ \text{no conclusion} & \text{otherwise} \end{cases} \quad (2)
$$

where

$$
\begin{align*}
K(X_{(t,t+h)} \in D_k) &\rightarrow \text{if } (Q_{\text{air}}^{\text{measured}} < Q_{\text{air}}^{\text{min}}) \\
V(X_{(t,t+h)} \in D_v) &\rightarrow (\text{obs}(\text{occupancy}) \in (\text{occupancy}_{\text{min}}, \text{occupancy}_{\text{max}}) \\
&\qquad \land (\text{obs}(\text{door or window position}) \in (\text{close}, \text{open}))
\end{align*}
$$

Possible fault explanations for Test2:

faulty supply or return fan ∨ broken ductwork ∨ faulty reconfiguration system ∨ electrical drive is
out of order ∨ broken or pierced ventilation pipes ∨ clogged filters.

Required sensors for validity:

* obs(occupancy) : estimated based on power consumption and indoor CO₂ level

- obs(door or window position) : contact sensor

Required measurement for behavior:

- obs(Q<sub>air</sub>) : airflow meter measurement

- obs(occupancy) : estimated based on power consumption and indoor CO₂ level

- obs(door or window position) : contact sensor

Assumption:

Sensors used for behavioral and validity constraints are in ok state.

4.3. Test3 (Zonal Thermal Test), Model-Based

A simplified model is used for estimating the indoor temperature (T<sub>est</sub>). Simplified models are
easy to initialize due to fewer parameters and only account for zonal properties [24]. Estimated
temperature (T<sub>est</sub>) is compared with the measured temperature (T<sub>measured</sub>) and ΔT is a small value.
Likewise, like rule- and range-based tests, model-based tests must also satisfy the behavioral and
validity constraints. For this test, possible explanations are obtained from the modeled component in
considering the model.

Modal-based zonal test:

$$
\textbf{Test3}(T_{est}) = \begin{cases} \text{inconsistent} & \text{if } \left( \neg(K(X_{(t,t+h)} \in D_k) \land V(X_{(t,t+h)} \in D_v) \right) \\ \text{consistent} & \text{if } \left( (K(X_{(t,t+h)} \in D_k) \land V(X_{(t,t+h)} \in D_v) \right) \\ \text{no conclusion} & \text{otherwise} \end{cases} \quad (3)
$$

where

$$
\begin{align*}
K(X_{(t,t+h)} \in D_k) &\rightarrow (T_{\text{measured}} - \Delta T \le (T_{\text{est}})) \land (\text{obs}(T_{\text{in}}) \le T_{\text{measured}} + \Delta T) \\
V(X_{(t,t+h)} \in D_v) &\rightarrow (\text{obs}(\text{occupancy}) \in (\text{occupancy}_{\text{min}}, \text{occupancy}_{\text{max}}) \\
&\qquad \land (T_{\text{out}} \in (T_{\text{min}}^{\text{weather predicted}}, T_{\text{max}}^{\text{weather predicted}}) \\
&\qquad \land (\text{obs}(\text{door or window position}) \in (\text{close, open}))
\end{align*}
$$
Possible fault explanations for Test 3:

open door or window ∨ inefficient ventilation system ∨ inefficient heating system ∨ unplanned appliances ∨ misconfigured or faulty BEMS.

Required sensors for validity:

* obs(occupancy) : estimated based on power consumption and indoor CO₂ level

* obs(Tout) : outdoor sensor reading

* obs(door or window position) : contact sensor

Required sensors for behavior:

* obs(Tin) : indoor temperature sensor reading

* obs(occupancy) : estimated based on power consumption and indoor CO₂ level

* obs(Tout) : outdoor sensor reading

* obs(door or window position) : contact sensor

Assumption:

Sensors used for behavioral and validity constraints are in ok state.

## 5. Analyzing Heterogeneous Tests

In practice, two diagnosis approaches have been widely adopted. The first is fault detection and isolation (FDI) supported by the control community [25] and focuses on model-based testing exclusively. FDI assumes abnormality in modeled behavior, which implies faults in the system. The second is inspired from artificial intelligence and known as logical diagnosis (DX) [26,27]. The DX approach mainly deals with the static system and adopts consistency-based diagnosis (CBD). DX assumes that faulty behavior cannot be determined only by behavior; it should involve components. In recent scientific literature, the importance of component-level analysis applied to a complex system to improve decision-making is explained in [28,29]. Moreover, multiple fault diagnosis is also a challenging task for FDI, though DX can deal with it easily.

To deal with the limitations of FDI and DX approaches, a group of contemporary researchers [18,30,31] have proposed a BRIDGE (FDI and DX) approach. The BRIDGE is applicable for both static and dynamic systems under certain conditions. The mainstay of the BRIDGE approach is the capability of finding a diagnosis with a component-level explanation.

In the present application, a logic-based BRIDGE [18,32] with formal diagnosis is used for diagnoses analysis. An example of logical reasoning for Test is given below:

$$ \textbf{Test} = \begin{cases} \textit{consistent} (0) & \text{if: } ((K(X_{(t,t+h)}) \in D_k) \land V(X_{(t,t+h)}) \in D_v) \\ \textit{inconsistent} (1) & \text{if: } (\neg(K(X_{(t,t+h)}) \in D_k) \land V(X_{(t,t+h)}) \in D_v) \\ \textit{no conclusion} & \text{otherwise} \end{cases} \quad (4) $$

where ∧ is a logical AND operator with K and V as behavioral and validity constraints, respectively. BRIDGE uses the notion of normalized Hamming distance (dH) (Definition 8) and the possible diagnosis explanation [18]. Moreover, it is assumed that an absence of symptoms does not imply an absence of defect. However, a restoration event such as a window closing could occur while performing the test over a batch of data. BRIDGE explicitly uses the diagnosis based on the row analysis of the signature table.

### 5.1. Diagnoses Explanation

All possible explanations from rule-, range-, and model-based tests are merged into a single fault-signature table for further analysis. It is a tabular representation of faults in the form of tests with
(0) and (1) where (1) means a fault is potentially detected for the related test, otherwise (0). This table can be obtained from cause-consequence analysis between system component and linked test.

To explain the proposed approach, a short and concrete example is chosen below. Consider the following signature table that combines rule-, range-, and model-based test explanations. Furthermore, range-, rule-, and model-based tests are performed over the set of data. This set of data consists of behavioral and validity data for the tested variable.

Furthermore, the test result (Equation (5)) i.e., symptoms coming from above three tests are inconsistent (represented by 1):

$$ \begin{bmatrix} \text{Test1} \\ \text{Test2} \\ \text{Test3} \end{bmatrix} = \begin{bmatrix} 1 \\ 1 \\ 1 \end{bmatrix} \qquad (5) $$

This symptom could be explained in terms of a combination of non-zero elements in each row of the signature Table 2. The conventional column-based diagnoses approach such as FDI could detect only a ventilation system as a fault. In contrast to FDI, the BRIDGE approach develops a row-based test *Explanation* for each inconsistent test. Furthermore, a possible explanation for the above symptoms could be given as:

$$ \begin{aligned} \text{Expl(Test1)} &= \text{not ok(ventilation system)} \lor \text{not ok(heating system)} \lor \text{not ok(duct)} \lor \text{not ok(boiler)} \\ \text{Expl(Test2)} &= \text{not ok(ventilation system)} \lor \text{not ok(duct)} \\ \text{Expl(Test3)} &= \text{not ok(ventilation system)} \lor \text{not ok(heating system)} \end{aligned} $$

These explanations are considered to be all possible sets of conflicts that could be responsible for the related faults. A Hitting set algorithm (Definition 7) described in [26], could be used for conflict analysis, which is depicted in Figure 3.

<table><caption>**Table 2.** Deduced signature table form all possible explanations.</caption><thead><tr><th>Test</th><th>not ok(ventilation system)</th><th>not ok(heating system)</th><th>not ok(duct)</th><th>not ok(boiler)</th></tr></thead><tbody><tr><td>Test1 (range-based) (Equation 1)</td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Test2 (rule-based) (Equation 2)</td><td>1</td><td>0</td><td>1</td><td>0</td></tr><tr><td>Test3 (model-based) (Equation 3)</td><td>1</td><td>1</td><td>0</td><td>0</td></tr></tbody></table>

1 = not ok (component), 0 = ok (component)

**Definition 7.** (Hitting set) A hitting set H for the ok(Components stats) = {$c_1, c_2, c_3, ..., c_n$} ⊆ ok(COMPONENTS) if H ⊆ $U_{1≤k≤n}c_n$, and H ∩ $c_n ≠ \{\}$. Set H is minimal if and only if $\forall X ⊂ H, X$ is not a Hitting set.

**Definition 8.** (Normalized Hamming distance) For given two equal-length binary vectors $b_1$ and $b_2$, normalized Hamming distance $d_H$ is defined as $d_H(b_1, b_2) = (\text{bit-wise changes in } b_1 \text{ and } b_2) / (\text{number of bits in } b_1 \text{ or } b_2)$.

To follow a fault-isolation process, normalized Hamming distance measures the closeness between the observed symptom and each column of Table 2. Knowing that Test 1, Test 2, and Test 3 are giving faulty results (Equation (5)), the normalized Hamming distance ($d_H$) is given below. This distance is computed between the observed signature (Equation (5)) and each column of Table 2.
$$
\begin{align*}
d_H(\text{not ok}(\text{ventilation system})) &= 0 \\
d_H(\text{not ok}(\text{heating system})) &= 0.33 \\
d_H(\text{not ok}(\text{duct})) &= 0.33 \\
d_H(\text{not ok}(\text{boiler})) &= 0.66
\end{align*}
$$

Using Hamming distance analysis, it is very obvious that *not ok(ventilation system)* is a declared
fault because it is closer to the first column in the test signature table. However, the bridge method goes
to the next level of analysis based on test explanations and tries to find a minimum possible explanation
for all faults. Also, ventilation is present in all test explanations marked as green, i.e., diagnosed in the
beginning of HS-tree (Figure 3). Now, the other nodes follow an expansion considering the next set
of explanation.

<figure><img src="image_5.png" /><figcaption>Figure 3. Hitting Set (HS) tree.</figcaption></figure>

In Figure 3, nodes with green labels show the diagnosed *component*, while the nodes in the
red represent the termination or blocked diagnosis process so that no additional work is required.
The following equation shows the set diagnosed component achieved from Figure 3.

$$
\text{Minimum diagnostic Explanation} = \text{not ok}(\text{ventilation system}) \wedge ((\text{not ok}(\text{heating system}) \vee \text{not ok}(\text{duct})))
$$

In this example, diagnosis detects the problem in the ventilation, duct, and heating system. Hence,
it will be easy to detect multiple faults in one diagnostic explanation.

6. An Application of Proposed Methodology for Center for Studies and Design of Prototypes (CECP) Building

In this section, a case study is presented to discuss the diagnosability issue in the so-called center
for studies and design of prototypes (CECP) building, which is an energy-efficient building constructed
in 2012 and located in Angers, France. The building has one floor, and about 20 rooms. The whole building is divided into 74 zones with two major parts, namely a workshop area of 700 m² and an office area of 1000 m². About 30 people work in this building.

CECP follows the French energy efficiency building code RT-2005 for heating, cooling, ventilation, hot water supply, and lighting. According to the French building code, its energy consumption is labeled as 55.33 kWh/m²/year for the workshop area and 55.59 kWh/m²/year for the office area, respectively. A 3D view of the CECP building is shown in Figure 4. Each zone in the building is different from the other in terms of temperature and comfort requirement.

<figure><img src="image_6.png" /><figcaption>Figure 4. 3D view of CECP Building.</figcaption></figure>

## 6.1. CECP Building Instrumentation

To monitor the CECP building, the following measuring points have been installed (Figure 5).

* on-site weather station (temperature, relative humidity, horizontal radiation, wind speed, and direction)

* ambient indoor temperatures in most rooms of the building (Ta); some sensors can also measure humidity (TH)

* heat energy in the boiler room for each outlet (for low-temperature radiators in the office area, etc.)

* electrical energy (W) for each differential circuit breaker to separate (lighting consumption, consumption of office outlets, consumption of auxiliaries etc.)

* motion detectors in most of the offices (CP)

* CO₂ concentration sensors in the corridors, in the meeting rooms, and in some offices.

* passage detectors at the entrances and exits of the building (E/S)

* some surface temperatures (Ts) sensors

* most of the offices are equipped with luxmeters
<figure><img src="image_7.png" /><figcaption>Figure 5. Building plan and instrumentation.</figcaption></figure>

## 6.2. ARX (Auto Regressive) Thermal Model

An ARX model with exogenous input has been used to model the normal and fast dynamic behaviors of the CECP building. This is a simple-to-implement thermal model without deep mathematical knowledge of the building system under study. Moreover, this model neither takes into account the existing links between parameters nor the physical relationships between variables. The building energy simulation divides the office part into 74 thermal zones. Each zone in the building is different from the other in terms of temperature and comfort requirement. The inputs of the simulation correspond to measurements that were made in 2015:

* indoor temperature is the one that has been measured in each zone

* internal gains come from measured electrical appliances (global measurement)

* meteorological conditions that have been measured on site

The model takes into account parameters that have not been measured, for example:

* human presence.

### Parameter identification:

Model parameters are estimated by the least-squares identification to minimize the error between estimation and measurements [33,34]. Two sets of separated data set between January 2015 and December 2015 have been used for the estimation and validation process. All inputs are measured on site, and output of the model is estimated with the help of Equation (6).

### Mathematical representation:

$$ T[k] = 0.226378T[k-1] - 0.002148U_0[k] + 0.052236U_1[k] - 0.000062U_2[k] \\ +0.000029U_3[k] - 0.000228U_4[k] + 0.012467U_5[k] - 0.656953U_6[k] \\ -0.450027U_7[k] + 0.450887U_8[k] + 0.283410U_9[k] \\ +0.423809U_{10}[k] + 0.020218 \quad (6) $$

### Input:

* $U_0 = T_{ext}$: Outdoor temperature
* $U_1 = T_{corridor}$ : Air temperature in the corridor

* $U_2 = W_{electrical}$ : Electrical consumption in office 009

* $U_3 = Q_{horizontal}$ : The horizontal radiation

* $U_4 = Airflow$ : Airflow in the office 009

* $U_5 = T_{vent}$ : Temperature of air blown in the office 009

* $U_6 = Q_{radiator}$ : Radiator heat flow

* $U_7 = T_{office101}$ : Air temperature in neighboring office 101

* $U_8 = T_{office010}$ : Air temperature in neighboring office 010

* $U_9 = T_{atel\_prod}$ : Air temperature in the room ATEL-PROD

* $U_{10} = Occupancy$ : Occupancy in office 009

**Output:**

* $T = T_{office009}$ : Output estimated temperature in office 009

**Sensitivity analysis:**

The goal of the sensitivity analysis is to highlight critical parameters for building performance. These are parameters whose values have a great influence on the model result. The implementation of a performance contract could therefore contain a clause concerning these parameters. *Morris method* is used to perform the sensitivity analysis. The objective here is not to precisely know the value of the effects of each parameter, but rather to rank or even select the most influential parameters. The standard deviation of the associated elementary effects is also calculated in the following table (Table 3). Each parameter is associated with a high and a low value defining a range of uncertainty chosen by an expert and/or by comparison with the scientific literature.

<table><caption>Table 3. Sensitivity analysis for important parameter.</caption><thead><tr><td>Uncertain Parameters</td><td>Low Level</td><td>Average</td><td>Standard Deviation</td></tr></thead><tbody><tr><td>indoor temperature (T<sub>in</sub>)</td><td>-2 K</td><td>20.7 °C</td><td>+2 K</td></tr><tr><td>number of occupants</td><td>-60%</td><td>average profile</td><td>+60%</td></tr><tr><td>internal gain from occupants</td><td>-50%</td><td>8 W/m<sup>2</sup> per occupation</td><td>+50%</td></tr><tr><td>outdoor temperature</td><td>-2 K</td><td>weather norm</td><td>+2 K</td></tr><tr><td>horizontal solar radiation</td><td>-50%</td><td>weather norm</td><td>-50%</td></tr></tbody></table>

### 6.3. Simulated Fault Scenario

TRNsys (simulation software) with interface TRNBuild and TRNsys Simulation Studio (graphical front-end) have been used to simulate the building faults. TRNBuild interface allows adding the non-geometrical properties such as wall and layer material properties, window and door properties, thermal conductivity and different gains etc. In the present work, these values are taken from the French building code. Table 4 and Figure 6 show the simulated fault scenario over a data set, namely Batch 1, Batch 2, and Batch 3, for a 24-hour duration.

Faults are simulated by adding or tuning different parameters in the fault model. The detail of simulated faults is given below:

* open window: using a TRNsys model

* unplanned occupancy: considered to be abnormal occupancy, i.e., a large number of occupants are more present than allowed. In this scenario 10 occupants are considered; however, the usual occupancy is 4.

* unplanned appliances: use of additional appliances, causing internal heat gain and over-consumption. In the present case study, a heater of 2kW/h is simulated as the unplanned appliance.
<table><caption>**Table 4.** Simulated fault scenario.</caption><thead><tr><th>Hour</th><th>Simulated Fault</th><th>Data Set Used</th></tr></thead><tbody><tr><td>0-1</td><td>-</td><td></td></tr><tr><td>1-2</td><td>-</td><td></td></tr><tr><td>2-3</td><td>-</td><td></td></tr><tr><td>3-4</td><td>-</td><td></td></tr><tr><td>4-5</td><td>-</td><td></td></tr><tr><td>5-6</td><td>-</td><td></td></tr><tr><td>6-7</td><td>window is open</td><td>Batch 1</td></tr><tr><td>7-8</td><td>window is open</td><td></td></tr><tr><td>8-9</td><td>window is open</td><td></td></tr><tr><td>9-10</td><td>window is open</td><td></td></tr><tr><td>10-11</td><td>unplanned appliances, unplanned occupancy</td><td></td></tr><tr><td>11-12</td><td>unplanned appliances, unplanned occupancy</td><td></td></tr><tr><td>12-13</td><td>unplanned appliances, unplanned occupancy</td><td>Batch 2</td></tr><tr><td>13-14</td><td>unplanned appliances, unplanned occupancy</td><td></td></tr><tr><td>14-15</td><td>unplanned appliances</td><td></td></tr><tr><td>15-16</td><td>unplanned appliances</td><td></td></tr><tr><td>16-17</td><td>unplanned appliances</td><td></td></tr><tr><td>17-18</td><td>unplanned appliances</td><td></td></tr><tr><td>18-19</td><td>unplanned appliances</td><td>Batch 3</td></tr><tr><td>19-20</td><td>unplanned appliances</td><td></td></tr><tr><td>20-21</td><td>unplanned appliances</td><td></td></tr><tr><td>21-22</td><td>unplanned appliances</td><td></td></tr><tr><td>22-23</td><td>unplanned appliances</td><td></td></tr><tr><td>23-24</td><td>unplanned appliances</td><td></td></tr></tbody></table>

<figure><img src="image_8.png" /><figcaption>**Figure 6.** Simulated fault scenario for office 009.</figcaption></figure>

## 6.4. Tests Analysis for (CECP) Building

In this case study, only the thermal performance of the building has been tested. The range and model-based tests are proposed in Sections 4.1 and 4.3. A range-based thermal test confirms a thermal discomfort and symptom manifest when the indoor temperature goes beyond the comfort boundary, i.e., 18 °C ($T_{min}$) and 22 °C ($T_{max}$).

Figure 7 shows thermal discomfort is detected between the hours of 6 to 169. Beyond the maximum and minimum temperature range, a building enters the thermal discomfort zone. This test confirms the discrepancy in the building's normal thermal performance.
<figure><img src="image_9.png" /><figcaption>Figure 7. Range-based thermal test for thermal discomfort.</figcaption></figure>

An ARX model-based zonal test is used to test the thermal performance at the zonal level. A model-based zonal test (Section 4.3) is used to verify the zonal temperature. This test performs a comparison of the measured and estimated temperature. The thermal model verifies the thermal discomfort at the zonal or local level. This test yields the set-point deviation symptom along with the thermal discomfort. Figure 8 shows the measured and estimated temperature value.

<figure><img src="image_10.png" /><figcaption>Figure 8. Model-based zonal thermal test for thermal discomfort in office 009.</figcaption></figure>

The zonal test is performed with the help of the linear regression model (Equation (6)) [33]. It compares whether the measurements follow the estimated temperatures or not. However, zonal temperature can adjust $±ΔT°C = 2°C$.

Moreover, the following set of validity constraints are used to analyze the test validity.

$$V(X_{(t,t+h)} \in D_v) \rightarrow (\text{obs}(\text{occupancy}) \in (\text{occupancy}_{\text{min}}, \text{occupancy}_{\text{max}}) \land (\text{obs}(\text{window position}) \in (\text{close}, \text{open}))$$

These constraints verify the window position and occupancy level (Figure 6).

## 6.5. Symptoms Analysis for CECP Building

This section demonstrates the experimental validation of the proposed diagnosis methodology. The tests were performed for the different building zones which include several offices and meeting rooms. Tests are derived from the one-week data collection from the CECP building. To make a concise explanation only the first 24-hours i.e., one day with three different scenarios and data set (Batch 1,2 &3), are accounted for in the fault analysis.

Table 5 represents the test results in three different scenarios. Conclusions from Table 5 are:

* there is no inconsistency between the hours 0 and 5 which confirms the normal building operation.

* during the hours 5–6 only Test3 is inconsistent.

* in the period 6–10 Test 1 shows no conclusion due to an open window in the morning.

* finally, all tests demonstrate inconsistency in building performance during the 10 to 24.
<table><caption>**Table 5.** Validity and behavioral constraints for tests.</caption><thead><tr><th>Hour</th><th>Test1 (Equation 1)</th><th>Test3 (Equation 3)</th><th>Conclusion (Test1)</th><th>Conclusion (Test3)</th></tr></thead><tbody><tr><td>0-1</td><td>K = 0, V = 0</td><td>K = 0, V = 0</td><td>consistent</td><td>consistent</td></tr><tr><td>1-2</td><td>K = 0, V = 0</td><td>K = 0, V = 0</td><td>consistent</td><td>consistent</td></tr><tr><td>2-3</td><td>K = 0, V = 0</td><td>K = 0, V = 0</td><td>consistent</td><td>consistent</td></tr><tr><td>3-4</td><td>K = 0, V = 0</td><td>K = 0, V = 0</td><td>consistent</td><td>consistent</td></tr><tr><td>4-5</td><td>K = 0, V = 0</td><td>K = 0, V = 0</td><td>consistent</td><td>consistent</td></tr><tr><td>5-6</td><td>K = 0, V = 0</td><td>K ≠ 0, V = 0</td><td>consistent</td><td>inconsistent</td></tr><tr><td>6-7</td><td>K ≠ 0, V ≠ 0</td><td>K ≠ 0, V = 0</td><td>no conclusion</td><td>inconsistent</td></tr><tr><td>7-8</td><td>K = 0, V ≠ 0</td><td>K = 0, V = 0</td><td>no conclusion</td><td>inconsistent</td></tr><tr><td>8-9</td><td>K = 0, V ≠ 0</td><td>K ≠ 0, V = 0</td><td>no conclusion</td><td>inconsistent</td></tr><tr><td>9-10</td><td>K = 0, V ≠ 0</td><td>K ≠ 0, V = 0</td><td>no conclusion</td><td>inconsistent</td></tr><tr><td>10-11</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>11-12</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>12-13</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>13-14</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>14-15</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>15-16</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>16-17</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>17-18</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>18-19</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>19-20</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>20-21</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>21-22</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>22-23</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr><tr><td>23-24</td><td>K ≠ 0, V = 0</td><td>K ≠ 0, V = 0</td><td>inconsistent</td><td>inconsistent</td></tr></tbody></table>

## 6.6. Heterogeneous Tests Analysis and Diagnosis Result

To simplify the approach, office room 009 of CECP building has been chosen for the diagnosis analysis. A few building components such as ventilation pipes, radiator, BEMS, etc. are considered to be possible test explanations. A heterogeneous test signature table below is developed, considering the range and model-based test.

Test explanations are computed from the all possible explanations given in Table 6. These explanations have conflicting components and require further analysis.

<table><caption>**Table 6.** Heterogeneous test signature table CECP building.</caption><thead><tr><th>Test</th><th>not ok(filter ∨ radiator ∨ pipes)</th><th>not ok(ventilation ∨ BEMS ∨ appliances)</th><th>not ok(occupancy ∨ door or window position)</th></tr></thead><tbody><tr><td>Test1 (range-based) (Equation 1)</td><td>1</td><td>0</td><td>1</td></tr><tr><td>Test3 (model-based) (Equation 3)</td><td>0</td><td>1</td><td>1</td></tr></tbody></table>

1 = not ok (component), 0 = ok (component).

### Scenario 1

#### Hour (0-5)

* Simulated fault: no fault has been simulated

* Detected symptom

$$ \begin{bmatrix} \text{Test1} \\ \text{Test3} \end{bmatrix} = \begin{bmatrix} 0 \\ 0 \end{bmatrix} \rightarrow (\text{consistent test result}) $$

In this duration, both tests are consistent and satisfy the behavioral and validity constraints. No inconsistency is revealed.
## Hour (5–6)

* Simulated fault: no fault has been simulated

* Detected symptom

$$ \begin{bmatrix} Test1 \\ Test3 \end{bmatrix} = \begin{bmatrix} 0 \\ 1 \end{bmatrix} \rightarrow (\text{consistent and inconsistent test result}) $$

In this hour, only Test 3 shows inconsistency. That confirms a zonal thermal discomfort. The test explanation for this test is given below:

$$ \begin{array}{l} Expl(Test3) = not\ ok(ventilation \lor BEMS \lor appliances) \\ \quad \land not\ ok(occupancy \lor door\ or\ window\ position) \end{array} $$

The fault explanation shows the problem could be an open window or unplanned occupancy. Also, poor or faulty ventilation system, wrongly configured BEMS, and unplanned appliances could be a considerable fault. Indeed, there is no simulated fault in this hour. So far, at this stage it is difficult to say what is the reason behind this inconsistency.

## Scenario 2

## Hour (6–10)

* Simulated fault: open window

* Detected symptom

$$ \begin{bmatrix} Test1 \\ Test3 \end{bmatrix} = \begin{bmatrix} no\ conclusion \\ 1 \end{bmatrix} \rightarrow (\text{no conclusion and inconsistent test result}) $$

During the hours 6–10, Test 1 shows no conclusion because of opening of the window and not considered for further analysis. However, Test 3 is still inconsistent, which means the fault is still present in the system. The Test explanation is same as the previous scenario.

$$ \begin{array}{l} Expl(Test3) = not\ ok(ventilation \lor BEMS \lor appliances) \\ \quad \land not\ ok(occupancy \lor door\ or\ window\ position) \end{array} $$

However, compared to the simulated fault scenario, the obvious reason behind this fault is *not ok(door or window position)*. The actual fault scenario is the open window. Diagnosis analysis detects this fault along with other faults.

## Scenario 3

## Hour (10–24)

* Simulated fault: unplanned appliances, unplanned occupancy

* Detected symptom

$$ \begin{bmatrix} Test1 \\ Test3 \end{bmatrix} = \begin{bmatrix} 1 \\ 1 \end{bmatrix} \rightarrow (\text{inconsistent test result}) $$
In this duration, both tests show inconsistencies and a conflicting situation arising in the diagnosis. Therefore, the Hamming distance between observed symptom and Table 6 is give below:

$$ 
\begin{aligned}
d_H(\text{not ok(filter} \lor \text{radiator} \lor \text{pipes})) &= 0.5 \\
d_H(\text{not ok(ventilation} \lor \text{BEMS} \lor \text{appliances})) &= 0.5 \\
d_H(\text{not ok(occupancy} \lor \text{door or window position})) &= 0
\end{aligned}
$$

Test explanations are:

$$ 
\begin{aligned}
\text{Expl(Test1)} &= \text{not ok(filter} \lor \text{radiator} \lor \text{pipes}) \land \text{not ok(occupancy} \lor \text{door or window position}) \\
\text{Expl(Test3)} &= \text{not ok(ventilation} \lor \text{BEMS} \lor \text{appliances}) \land \text{not ok(occupancy} \lor \text{door or window position})
\end{aligned}
$$

Furthermore, bridge diagnosis analysis finds the following faults as possible diagnosis:

$$ 
\begin{aligned}
\text{Minimum diagnostic ExplAnation} &= \text{not ok(occupancy} \lor \text{door or window position}) \\
&\quad \land (\text{not ok(filter} \lor \text{radiator} \lor \text{pipes}) \\
&\quad \lor \text{not ok(ventilation} \lor \text{BEMS} \lor \text{appliances}))
\end{aligned}
$$

BRIDGE analyzes both test explanations and most reasonable issues are occupancy and building openings, i.e., door or window open. This confirms that faults with open window are still present in the system.

The simulated fault in this scenario is unplanned appliances and unplanned occupancy. BRIDGE diagnosis confirms that at least one of the combinations, i.e., (occupancy ∨ door or window) is faulty. However, the other simulated fault, unplanned appliance, is detected with faulty not ok(ventilation ∨ BEMS ∨ appliances), i.e., the issue with the ventilation system, unplanned appliances or failure of BEMS.

Furthermore, the diagnosis is terminated with at least two combinations of minimal diagnoses, which are:

$$ 
\begin{aligned}
\text{not ok(occupancy} \lor \text{door or window position}) \text{ AND} \\
\text{not ok(filter} \lor \text{radiator} \lor \text{pipes}) \lor \text{not ok(ventilation} \lor \text{BEMS} \lor \text{appliances})
\end{aligned}
$$

Diagnosis results are illustrated in Figure 9. The results have proved that at least one of these combinations must be faulty. In conclusion, the proposed diagnosis approach can detect simulated faults with validity under the single and multiple fault scenarios. At the same time, the minimum diagnosis explanation addresses the all possible faults and reduces the further search process.

<figure><img src="image_11.png" /><figcaption>Figure 9. HITTING SET (HS)-tree for diagnosed faults.</figcaption></figure>
## 7. Conclusions

The advantage of providing a building diagnostic system based on contextual tests and consistency analysis are three-fold. First, the validity of diagnosed fault can be verified easily. Proposed contextual tests are valid under certain contexts and relatively easy to apply under real building conditions. Second, the knowledge from heterogeneous tests can be combined into one fault diagnosis analysis. This scales down the whole-building fault modeling effort. Lastly, a minimum set of possible faulty components is derived from the consistency analysis method. Such explanations allow an easy fault-isolation process. The results show that the proposed methodology can diagnose multiple fault scenarios. Given the set of minimum explanations, a facility manager can determine what may be wrong with the building system being diagnosed. The limitation of the proposed contextual and heterogeneous tests is that they rely on an assumption i.e., non-faulty sensors and actuators. Moreover, a faulty sensor or measurement could disturb the applicability of the proposed methodology. The future of the proposed work is to develop a comprehensive whole-building fault-analytics tool that could incorporate sensor failures. Also, future work will focus on designing of different test at component level and sub-component level. We are willing to extend our approach for developing an interactive building fault diagnosis tool combining the domain expert knowledge and experience.

**Author Contributions:** M.S. and S.P. conceptualize the idea and wrote the paper; N.T.K. and H.N. performed experiments; A.C. reviewed the idea and helped in data acquisition.

**Funding:** This work is supported by the French National Research Agency in the framework of the "Investissements d'avenir" program (ANR-15-IDEX-02) as the cross disciplinary program Eco-SESA.

**Conflicts of Interest:** The authors declare no conflict of interest.

## Abbreviations

<table><tr><td>FDD</td><td>Fault Detection and Diagnosis</td></tr><tr><td>DX</td><td>Logical Diagnosis</td></tr><tr><td>BRIDGE</td><td>FDI + DX</td></tr><tr><td>BEMS</td><td>Building Energy Management System</td></tr><tr><td>FDI</td><td>Fault Detection Isolation</td></tr><tr><td>DEAF</td><td>Diagnostic Explanation Feature</td></tr><tr><td>CECP</td><td>Center for Studies and Design of Prototypes</td></tr><tr><td>ARX</td><td>Auto Regressive model</td></tr></table>

## Notations

<table><tr><td>✓</td><td>Logical OR</td></tr><tr><td>∧</td><td>Logical AND</td></tr><tr><td>≠</td><td>Not in</td></tr><tr><td>X</td><td>Set of variables</td></tr><tr><td>D<sub>v</sub></td><td>Bound domain of validity constraints</td></tr><tr><td>D<sub>k</sub></td><td>Bound domain of behavioral constraints</td></tr><tr><td>K</td><td>Set of validity constraints</td></tr><tr><td>V</td><td>Set of behavioral constraints</td></tr><tr><td>¬</td><td>Negation</td></tr><tr><td>∀</td><td>For all</td></tr><tr><td>→</td><td>Implies</td></tr><tr><td>∃</td><td>Exists</td></tr><tr><td>obs</td><td>Observation</td></tr><tr><td>Tcorridor</td><td>Corridor temperature</td></tr><tr><td>T<sub>est</sub></td><td>Estimated temperature</td></tr><tr><td>T<sub>in</sub></td><td>Indoor temperature</td></tr><tr><td>d<sub>h</sub></td><td>Hamming distance</td></tr><tr><td>Eq</td><td>Equation</td></tr></table>
## References

1. Calvillo, F.C.; Sánchez-Miralles, A.; Villar, J. Energy management and planning in smart cities. *J. Renew. Sustain. Energy Rev.* **2017**, *55*, pp. 273-287.

2. Le, M.; Ploix, S.; Wurtz, F. Application of an anticipative energy management system to an office platform. In Proceedings of BS 2013—13th Conference of the International Building Performance Simulation Association, Chambéry, France, 26–28 August 2013.

3. Katipamula, S.; Brambley, M.R. Review article: Methods for fault detection, diagnostics, and prognostics for building systems, Part I. *Hvac&R Res.* **2005**, *11*, 3–26.

4. Katipamula, S.; Brambley, M.R. Review article: Methods for fault detection, diagnostics, and prognostics for building systems, Part II. *Hvac&R Res.* **2005**, *11*, 169–187.

5. Lazarova-Molnar, S.; Shaker, R.H.; Mohamed, N.; Jørgensen, N.B. Fault detection and diagnosis for smart buildings: State of the art, trends and challenges. In Proceedings of the 3rd MEC International Conference on Big Data and Smart City (ICBDSC), Muscat, Oman, 15–16 March 2016; pp. 1–7.

6. Wang, S.; Yan, C.; Xiao, F. Quantitative energy performance assessment methods for existing buildings. *Energy Build.* **2012**, *55*, 873–888.

7. Derouineau, S.; Fouquier, A.; Mohamed, A.; Perehinec, A.; Couilladus, N. Specifications for Energy Management, Fault Detection and Diagnosis Tools. Technical Report: Prepared for the European Project PERFORMER. 2015; pp. 35–55. Available online: http://performerproject.eu/wp-content/uploads/2015/04/PERFORMER_D1-4_Specification-for-energy-management-FDD-Tools.pdf (accessed on 1 September 2015)

8. Du, Z.; Jin, X.; Yang, Y. Fault diagnosis for temperature, flow rate and pressure sensors in VAV systems using wavelet neural network. *Appl. Energy* **2009**, *86*, 1624–1631.

9. Li, S.; Wen, J. A model-based fault detection and diagnostic methodology based on PCA method and wavelet transform. *Energy Build.* **2014**, *68*, 63–71.

10. O'Neill, Z.; Pang, X.; Shashanka, M.; Haves, P.; Bailey, T. Model-based real-time whole building energy performance monitoring and diagnostics. *J. Build. Perform. Simul.* **2014**, *7*, 83–99.

11. Najeh, H.; Singh, M.P.; Chabir, K.; Ploix, S.; Abdelkrim, N.M. Diagnosis of sensor grids in a building context: Application to an office setting. *J. Build. Eng.* **2018**, *17*, 75–83.

12. Schumann, A.; Hayes, J.; Pompey, P.; Verscheure, O. Adaptable Fault Identification for Smart Buildings. In Proceedings of the 7th AAAI Conference on Artificial Intelligence and Smarter Living: The Conquest of Complexity, San Francisco, CA, USA, 7–8 August 2011; pp. 44–47.

13. Oh, T.-K.; Lee, D.; Park, M.; Cha, G.; Park, S. Three-Dimensional Visualization Solution to Building-Energy Diagnosis for Energy Feedback. *Energies* **2018**, *11*, 1736.

14. Dey, A.K. Understanding and Using Context. *J. Pers. Ubiquitous Comput.* **2001**, *5*, 4–7.

15. Fazenda, P.; Carreira, P.; Lima, P. Context-based reasoning in smart buildings. In Proceedings of the First International Workshop on Information Technology for Energy Applications, Lisbon, Portugal, 6–7 September 2012; pp. 131–142.

16. Pardo, E.; Espes, D.; Le-Parc, P. A Framework for Anomaly Diagnosis in Smart Homes Based on Ontology. *Procedia Comput. Sci.* **2016**, *83*, 545–552.

17. Singh, M. Improving Building Operational Performance with Reactive Management Embedding Diagnosis Capabilities. PhD. Thesis, Université Grenoble Alpes, Grenoble, France, 2017.

18. Ploix, S. Des systèmes automatisés aux systèmes coopérants: application au diagnostic et à la gestion énergétique. In *Habilitation à diriger des recherches (HDR)*; Grenoble-INP, Grenoble, France, 2009; Chapter 3 and 5, pp. 43–51.

19. Gentil, S.; Lesecq, S.; Barraud, A. Improving decision making in fault detection and isolation using model validity. *Eng. Appl. Artif. Intell.* **2009**, *22*, 534–545.

20. Carli, R.; Dotoli, M.; Pellegrino, R. A Hierarchical Decision-Making Strategy for the Energy Management of Smart Cities. *IEEE Trans. Autom. Sci. Eng.* **2017**, *14*, 505–523.

21. Carli, R.; Dotoli, M. Decentralized control for residential energy management of a smart users microgrid with renewable energy exchange. *IEEE/CAA J. Autom. Sin.* **2019**, *6*, 641–656.
22. Hosseini, M.S.; Carli, R.; Dotoli, M. Model Predictive Control for Real-Time Residential Energy Scheduling under Uncertainties. In Proceedings of the 2018 IEEE International Conference on Systems, Man, and Cybernetics (SMC), Miyazaki, Japan, 7–10 October 2018; pp. 1386–1391.

23. Singh, M.; Ploix, S.; Wurtz, F. Handling Discrepancies in Building Reactive Management Using HAZOP and Diagnosis Analysis. In Proceedings of ASHRAE 2016 Summer Conference, St. Louis, MI, USA, 25–29 June 2016; pp. 1–8.

24. Wang, S.; Xu, X. Simplified building model for transient thermal performance estimation using GA-based parameter identification. *Int. J. Therm. Sci.* **2006**, *45*, 419–432.

25. Isermann, R. Model-based fault-detection and diagnosis—Status and applications. *Ann. Rev. Control* **2005**, *29*, 71–85.

26. Reiter, R. A Theory of Diagnosis from First Principles. *Artif. Intell.* **1987**, *32*, 57–95.

27. De Kleer, J.; Mackworth, A.K.; Reiter, R. Characterizing diagnoses and systems. *Artif. Intell.* **1992**, *56*, 197–222.

28. Leszek, C.; Michal, T.; Bogusz, W. Multi-criteria Decision making in Components Importance Analysis applied to a Complex Marine System. *J. Nase More* **2016**, *64*, 264–270.

29. Leszek, C.; Katarzyna, G. Selected issues regarding achievements in component importance analysis for complex technical systems. *Sci. J. Maritime Univ. Szczecin* **2017**, *52*, 137–144.

30. Ploix, S.; Touaf, S.; Flaus, J.M. A logical framework for isolation in faults diagnosis. *IFAC Proc. Vol.* **2003**, *36*, 807–812.

31. Cordier, M.O.; Dague, P.; Lévy, F.; Montmain, J.; Staroswiecki, M.; Travé-Massuyès, L. Conflicts versus analytical redundancy relations: A comparative analysis of the model based diagnosis approach from the artificial intelligence and automatic control perspectives in Systems, Man, and Cybernetics. *Syst. Man Cybern. Part B Cybern.* **2004**, *34*, 2163–2177.

32. Zhang, W.; Zhao, Q.; Zhao, H.; Zhou, G.; Feng, W. Diagnosing a Strong-Fault Model by Conflict and Consistency. *Sensors* **2018**, *18*, 1016.

33. Hoang, M.L.; Kien, T.N. Building thermal modeling using equivalent electric circuit: Application to the public building platform. *Autom. Today* **2015**, *14*, 26–33.

34. Ljung, L. *System Identification: Theory for the User*, 2nd ed.; Prentice Hall PTR: Upper Saddle River, NJ, USA, 1999.

<figure><img src="image_12.png" /></figure>

© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).