FSBrick: an information model for representing fault-symptom relationships in heating, ventilation, and air conditioning systems

Abstract

Current fault diagnosis (FD) methods for heating, ventilation, and air conditioning (HVAC) systems do not accommodate for system reconfigurations throughout the systems’ lifetime. However, system reconfiguration can change the causal relationship between faults and symptoms, which leads to a drop in FD accuracy. In this paper, we present Fault-Symptom Brick (FSBrick), an extension to the Brick metadata schema intended to represent information necessary to propagate system configuration changes onto FD algorithms, and ultimately revise FSRs. We motivate the need to represent FSRs by illustrating their changes when the system reconfigures. Then, we survey FD methods’ representation needs and compare them against existing information modeling efforts within and outside of the HVAC sector. We introduce the FSBrick architecture and discuss which extensions are added to represent FSRs. To evaluate the coverage of FSBrick, we implement FSBrick on (i) the motivational case study scenario, (ii) Building Automation Systems’ representation of FSRs from 3 HVACs, and (iii) FSRs from 12 FD method papers, and find that FSBrick can represent 88.2% of fault behaviors, 92.8% of fault severities, 67.9% of symptoms, and 100% of grouped symptoms, FSRs, and probabilities associated with FSRs. The analyses show that both Brick and FSBrick should be expanded further to cover HVAC component information and mathematical and logical statements to formulate FSRs in real life. As there is currently no generic and extensible information model to represent FSRs in commercial buildings, FSBrick paves the way to future extensions that would aid the automated revision of FSRs upon system reconfiguration.

Impact Statement

As a part of our research vision to create an adaptive fault diagnosis framework robust to system reconfiguration, this article offers a generic and extensible information modeling approach to represent fault-symptom relationships. Through this work, we (i) motivate the need for FSR representation from FD methods in the literature, (ii) compare them against representations possible in current information models in and out of the HVAC sector, (iii) offer a 25 entity and relationship extension to an existing information model, Brick, called FSBrick, and (iv) evaluate its coverage against three case studies that span multiple real HVAC systems.

1. Introduction

Faults in heating, ventilation, and air conditioning (HVAC) systems account for 20% of energy consumption in buildings (Deshmukh et al., 2020), which corresponds to approximately 2.4% of the total annual energy use of the United States, equivalent to approximately 2.4 quadrillion BTUs (United States Energy Information Administration [EIA], 2023). However, detecting and diagnosing these faults has proven difficult. A study led by Lawrence Berkeley National Laboratory found that while commercial fault detection tools for HVAC systems reached 83% accuracy, fault diagnosis (FD) only achieved 66% accuracy (Lin et al., 2020).

All FD methods learn the causal relationship between faults and symptoms, either explicitly or implicitly, based on some system assumption (e.g., system configuration). For example, a rule-based method, like air handling unit (AHU) performance assessment rules (APAR) (House et al., 2001), lists known fault and symptom pairs (explicitly), and supervised learning methods listed in (Mirnaghi and Haghighat, 2020) learn a function that maps symptoms to known faults (implicitly). These fault-symptom relationships (FSR) can change as a result of system reconfiguration (Hwang et al., 2024) (e.g., a fault, such as a fouled heating coil, may no longer be associated with a symptom, Rule 4, in APAR), and having a formal representation of them would facilitate the process of automatically updating the diagnosis methods. However, partly due to not having formal representation, current FD methods do not automatically adapt FSR to system configuration changes, and thus, are more susceptible to becoming inaccurate. For example, in the aforementioned study (Hwang et al., 2024), FD accuracy improved 70% for one of the actuator faults when the method was manually corrected to account for system reconfiguration. Once the assumptions on which the FD method is based on change, the FD method should automatically propagate changes to the relationship between faults and symptoms to maintain diagnosis accuracy.

Currently, subject matter experts (e.g., facility managers) manually modify FD tools in response to system configuration changes (e.g., addition/removal of thermal zones). Within the HVAC domain, both quantitative and qualitative model-based methods require an expert to intervene and change the model to account for system reconfigurations (Zhao et al., 2015, 2017; Yan et al., 2018; Velibeyoglu et al., 2019; Zhu et al., 2019; Qiu et al., 2020; Taal and Itard, 2020; Pradhan et al., 2021). The process history-based methods require labeled data to train classification functions for the new system configuration (Yan et al., 2019; Mirnaghi and Haghighat, 2020).

As shown in Figure 1, we propose a vision where an FD method can continuously adapt to system configuration changes. To fulfill this vision, a semantic model and a corresponding reasoning engine need to be developed to conjecture how a change in the system configuration will affect the existing FSR (e.g., will the relationship between existing FSR still hold?). Towards this vision, we survey the needs of information representation from existing FD methods, draw inspiration from existing semantic models both in and out of the HVAC sector, and build an extension to Brick, which can already represent elements necessary for FSR codification, unlike others. The main contribution of this paper is an extension to Brick, called Fault-Symptom Brick (FSBrick): a semantic model for commercial HVAC systems to represent part of the information necessary (i.e., FSR) to adapt FD algorithms to system configuration changes.

Figure 1. An illustration of the vision for automatically incorporating system configuration information in the FD method (classification function). We will specifically focus on FSBrick, which is a part of the information model.

The rest of the paper is organized as follows. First, in Section 2, we introduce a motivational case study, followed by a literature review on the needs of different FD methods in representing fault-symptom relationships and how existing information models fall short in representing necessary FSR information (Section 3). In addition, FSBrick (source code), the proposed extension to one of the existing information models (Brick), is motivated by the needs identified in HVAC FD and general information model literature and case study (Section 4). FSBrick is then tested for coverage across FSRs from (i) the case study, (ii) 3 AHUs and their Building Automation System (BAS) points, and (iii) 12 FD papers (Section 5). Finally, we have a summary of findings from the analyses and a discussion for future improvements (Section 6).

This paper builds upon previous research (Hwang et al., 2023) by providing (i) a more thorough synthesis of the FSR information requirement through literature review of FD methods (culminating in Table 1), (ii) 5 additional entities and ontological relationships to represent additional needs identified from the synthesis (e.g., grouped symptoms and probabilities for FSR mapping detailed in Section 4), and (iii) an expanded coverage analysis in Section 5 to further demonstrate the applicability and range of FSBrick.

2. Motivating case study

To better understand the requirements for the semantic model representing FSRs, we study various system reconfiguration scenarios and the resulting changes to specific faults and their symptoms in these systems. Specifically, we study a simplified thermal resistance-capacitance (RC) network model of a room with one cooling and one heating source calibrated with winter month data from Carnegie Mellon University’s (CMU) PhD student room AHU in Porter Hall. Thermal RC network models are commonly used in HVAC system behavior modeling literature (Hazyuk et al., 2012; Kircher and Zhang, 2015; Brastein et al., 2019; Boodi et al., 2020). Additionally, we consider three types of reconfigurations (i.e., addition, deletion, modification) at three different granularity levels (i.e., component level, subsystem level, system level), which were identified to be common system reconfigurations for HVAC systems (ASHRAE, 2018; Hwang et al., 2024).

Many commercial HVAC systems are composed of an AHU, which handles the preparation and distribution of conditioned air for the building, and a Variable Air Volume (VAV) (a terminal unit), which takes the air from the AHU and adjusts the zone temperature to the occupants’ liking. However, some FD algorithms (e.g., House et al., 2001; Yan et al., 2018) intended to work on AHUs do not account for the VAV’s behavior. Since applying the FD algorithm in the presence of the VAV may violate the assumptions, we are considering this as a system reconfiguration (specifically, a subsystem addition). Upon surveying common system reconfigurations on CMU campus, we concluded that subsystem level addition was the most common, and therefore, we will focus on this case. Another example of a more “physical” subsystem level addition can include multiple terminal units, such as Fan Coil Units and VAVs, working in the same zone due to zone-separating wall demolition, which occurred in Porter Hall three times, and twice in one year (Akcamete, n.d.).

To show how system reconfiguration affects FSR changes, we now parse the subsystem level addition example. To represent the AHU (system configuration before changes), we kept the RC network model of a room with one cooling and one heating source. Six faults were selected based on the cooling and heating manipulations possible in the RC network model. These six faults (i.e., Cooling Coil Valve Stuck Open, Cooling Coil Valve Stuck Closed, Cooling Coil Valve Leaking 20%, Heating Coil Valve Stuck Open, Heating Coil Valve Stuck Closed, Heating Coil Valve Leaking 20%) were inserted to the existing RC network model to generate the symptoms. We defined a Supply Air Temperature Alarm to be our symptom for when the internal temperature of the RC network model fell below 59°F or above 61°F. Threshold-based alarms, such as the one defined here, are commonly used in rule-based methods, such as in House et al. (House et al., 2001). Cooling Coil Valve Stuck Open and Heating Coil Valve Stuck Closed faults both triggered the Supply Air Temperature Alarm in the existing, unreconfigured system. To generate FSRs for the reconfigured system, we inserted one more heating source in the RC network model to represent the addition of a VAV with a reheat subsystem. This time, when the same faults were injected to the reconfigured system, we found that the Cooling Coil Valve Stuck Open and Heating Coil Valve Stuck Closed faults did not trigger the Supply Air Temperature Alarm. Therefore, we found that 2 out of 6 FSRs were altered by reconfiguration.

The case study example shows us that FSRs change with system reconfiguration and tracking this change automatically is crucial in maintaining FD accuracy. Having FSR representation would facilitate the process of automatically updating the FD diagnosis methods. In the next section, we will review the literature to find information models that may help us represent these FSRs more formally.

3. Literature review

In the case study section, we focused on how rule-based FD methods (which fall under the qualitative model-based FD methods) fell in diagnosis accuracy when system reconfiguration occurred. In this section, we will explore (i) the different types of FD methods in the HVAC sector and the common information requirements for representing faults, symptoms, and fault-symptom relationships; and (ii) how current information modeling sectors represent faults, symptoms, and fault-symptom relationships. The section will wrap up with a discussion surrounding the gaps that still exist in representing faults, symptoms, and fault-symptom relationships in Table 1.

Table 1. Needs identified for HVAC faults, symptoms, and fault-symptom relationships from FD methods literature review in comparison with what current information models can represent. The horizontal line delineates between FD method needs and information model capabilities

3.1. HVAC fault diagnosis methods

FD methods for the HVAC sector can be classified into the following three categories: (i) qualitative model-based, (ii) quantitative model-based, and (iii) process history-based methods with grey-box or hybrid method extensions for each category (Katipamula and Brambley, 2005a, 2005b; Kim and Katipamula, 2018). The summary of all methods reviewed can be seen in Figure 2.

Figure 2. FD method classification for the HVAC sector and built environment adapted and extended from Katipamula and Brambley (2005a, 2005b), Kim and Katipamula (2018), Venkatasubramanian et al. (2003), and Mirnaghi and Haghighat (2020). The bolded works are HVAC specific.

3.1.1. Qualitative model-based FD methods

Qualitative model-based FD methods involve encoding information about the system’s behavior in a knowledge base to refer to when isolating the fault (Chi et al., 2022). Among inductive reasoning methods, which are bottom-up approaches that derive conclusions based on individual observations, are case-based reasoning (Xu et al., 2018) and knowledge-graphs (Chen et al., 2020; Chi et al., 2022) (and their extension into providing causal graphs for grey-box fault diagnosis (Velibeyoglu et al., 2019; Zhu et al., 2019)). Another type of qualitative model-based FD method, the deductive reasoning methods, which are top-down approaches that conjecture about specific cases from general axioms stored in the knowledge base, includes rule-based reasoning (House et al., 2001; Delgoshaei and Austin, 2017) (and their extension into providing causal graphs for bayesian networks (Zhao et al., 2015; Zhao et al., 2017; Taal and Itard, 2020; Pradhan et al., 2021) and ontology-based reasoning (Zhou et al., 2015; Chen et al., 2015) methods. The shared foundation of these methods is their reliance on a knowledge base, which uses a unified taxonomy and ontology for information reuse and reasoning.

Faults in this area of literature were described with respect to their location and behavior. Location is the equipment in the system (e.g., a descriptive string) that is causing the anomalous behavior, while the behavior describes how the equipment is malfunctioning (e.g., a descriptive string). For example, House et al. (House et al., 2001) cite “Leaking heating coil valve” as a fault, where “heating coil valve” refers to the fault location and “leaking” refers to the fault behavior. Similarly, in the built environment, qualitative model-based FD method works, location (e.g., equipmentComponent—Zhou et al., 2015; faultEquipment—Xu et al., 2018; Fault_name—Chen et al., 2015) and behavior (e.g., failureCause—Zhou et al., 2015; faultCause—Xu et al., 2018) are included in the fault description.

Similarly, symptoms were described with respect to their sensed value and behavior. The sensed value is the observed variable from sensors deployed in the HVAC system (e.g., a descriptive string) and the behavior is the description of the anomaly (e.g., a descriptive string). For example, in Taal and Itrad (Taal and Itard, 2020), a symptom “high CO₂” is associated with the CO₂ (sensed value) and a higher than nominal measurement (a behavior of the CO₂ concentration with a threshold in mind). In the built environment qualitative model-based FD method works, measured value (e.g., sensed state variables—Velibeyoglu et al., 2019), vibration measurements (Chen et al., 2015) and behavior (e.g., vibration characteristics—Chen et al., 2015) are present in the symptom description.

Fault-symptom relationships were explicitly represented in qualitative model-based FD methods in various ways. House et al. (2001) used a table with faults and symptoms on the axes with check marks to indicate the relationships between them, Zhu et al. (2019) used graphical representation of arrows in between faults and symptoms with probability values associated with them, and Zhou et al. (2015), Chen et al. (2015), and Xu et al. (2018) used ontological relationships, such as “becauseOf/theEffectIs,” “causeIs/toEffect,” and “hasReason/isReasonOf.” Therefore, the fault-symptom relationships can be described by the connection between faults and symptoms (e.g., resource description framework [RDF] predicate or web ontology language [OWL] object property), the one to many nature of the connection (e.g., unified modeling language [UML] association), and probability values associated with the connection (e.g., a float value).

3.1.2. Quantitative model-based FD methods

Quantitative model-based FD methods involve modeling the system and comparing the model’s components, such as outputs, internal states, or unknown inputs, with sensor values from the real system to discern the presence of anomalous behavior, and finally isolate the fault cause (Venkatasubramanian et al., 2003). This comparison between the system model and the system itself can be realized through residual generation. There are different categories of residual generation methods, which is a concept thoroughly explored in the control theory space: (i) parity equations for system output estimation (Qiu et al., 2020), (ii) state observers and also input observers (Zhang et al., 2017; Naderi and Khorasani, 2018; Yan et al., 2018), (iii) frequency domain residuals (Frisk, n.d.), and (iv) parameter estimation (Isermann, 2005; Turner et al., 2017).

To contextualize residual formulation, we define a Linear Time Invariant (LTI) model, $ {\Sigma}^{\prime } $ , of the system, $ \Sigma $ :

(3.1) $$ {\displaystyle \begin{array}{l}\dot{x}(t)= Ax(t)+ Bu(t)+ Fw(t)\\ {}y(t)= Cx(t)+n(t)\end{array}} $$

The system model, $ {\Sigma}^{\prime } $ , has $ A $ as the dynamics matrix, $ B $ as the control matrix, $ C $ as the sensor matrix, and $ F $ as the fault relation matrix. The variables $ x\in {\mathrm{\mathbb{R}}}^k $ represent the state vector, $ y $ the output vector, $ w\in {\mathrm{\mathbb{R}}}^j $ the faulty input vector, $ u\in {\mathrm{\mathbb{R}}}^i $ the input vector, and $ n $ the measurement noise. Constant actuator faults, especially, were described with a fault severity value, $ {f}_s $ , from time $ {t}_0 $ to $ {t}_T $ (Frisk, n.d.; Xu and Zhang, 2004; Qiu et al., 2020):

(3.2) $$ w\left(t;{f}_s,{t}_0,{t}_T\right)={f}_s\hskip0.24em \mathrm{for}\hskip0.24em {t}_0\le t\le {t}_T $$

Therefore, faults, for this method class, are defined by their associated input variable to the system via actuator equipment (e.g., a descriptive string), fault severity (e.g., a float value), and time duration (e.g., reference (string) to a multi-dimensional array with timestamps and corresponding values). For example, in Qiu et al. (2020) the stuck actuator fault is described with $ n $ , the actuator to the system (associated input variable to the system), which can take a fixed value, $ R $ (fault severity) for time duration $ t\ge T $ .

An example of a residual generated for system, $ \Sigma $ , specifically for the parity equations that compare system output, can be described with the following equation:

(3.3) $$ r(t)=y(t)-\hat{y}(t) $$

where $ y(t) $ is the system output and $ \hat{y}(t) $ is the predicted system output generated from the system model, $ {\Sigma}^{\prime } $ . Similarly for state observer, input observer, frequency domain, and parameter estimation methods, the residual generation process involves a comparison of a vector from the real system $ v(t) $ with a vector from the system model $ \hat{v}(t) $ , with a predefined threshold, $ \varepsilon $ for time no earlier than when the fault enters the system ( $ {t}_1>{t}_0 $ ) to time $ T $ ( $ {t}_T $ ). The comparison vectors, $ v(t) $ and $ \hat{v}(t) $ , can be compared individually, for $ N $ vectors (i.e., $ v(t)\in {\mathrm{\mathbb{R}}}^{T\times N} $ ) with $ \varepsilon \in {\mathrm{\mathbb{R}}}^{T\times N} $ , or in groups, for $ M $ groups with $ \varepsilon \in {\mathrm{\mathbb{R}}}^{T\times M} $ .

Therefore, symptoms, for this method class, are defined by their associated system output variable (e.g., a descriptive string), possibly grouped and simultaneous nature (e.g., a list of strings (grouped system output variables)), predefined threshold for nominal behavior (e.g., a float value), and time duration (e.g., reference (string) to a multi-dimensional array with timestamps and corresponding values). For example, in Yan et al. (2018) the difference between the supply air temperature (associated system output variable) and its set-point (predefined threshold for nominal behavior) is considered for a time window (time duration).

Additionally, some quantitative model-based methods design residuals specifically for each fault (Jain et al., 2019), but others construct “influence structures” or “structured residuals” to classify which faults are present in the system based on the produced set of residuals (Venkatasubramanian et al., 2003; Frisk, n.d.; Svärd, n.d.). These influence structures are tables, much like the one used by House et al. (2001), with faults and symptoms on the axes with 0 or 1 to indicate the presence of relationships between them. Therefore, fault-symptom relationships for quantitative model-based FD methods, when represented, require the connection between faults and symptoms (e.g., a dictionary with key and value pairs) and the one to many nature of the connection (e.g., list of strings for the value in a dictionary).

3.1.3. Process history-based FD methods

Process history-based FD methods use data from the system to either train a model to recognize fault-symptom relationships (e.g., model-based, supervised methods) or determine a pattern in data (e.g., statistical, unsupervised methods) (Mirnaghi and Haghighat, 2020). Supervised methods, such as ones that use support vector machines (SVMs) or Neural Networks (NN) (Yan et al., 2019), train a diagnostic classifier with labeled fault and symptom pairs, and expect the trained classifier to identify the fault from real system outputs. Semi-supervised methods train a classifier with a limited number of fault training samples and pull from techniques, such as generative adversarial networks (GANs) (Li et al., 2021), active learning (Fan et al., 2024), and similarity learning (Chen et al., 2023) to also learn from unlabeled data sets. Finally, unsupervised methods require no labeled data, and only generate fault diagnosis results based on patterns in data using methods, such as clustering and associative rule mining (ARM) (Yu et al., 2012).

Among the process history-based methods that use labeled data (supervised and semi-supervised methods), the input to training the classifiers were matrices of system output variables, or features, that were labeled with fault classes. The faults were labeled with location, which is the affected system input via the actuator equipment to the system (e.g., descriptive string), behavior, which is the description of how the equipment is malfunctioning (e.g., a descriptive string), and intensity, which adds a numeric description of the degree of malfunctioning (e.g., a float value). In Yan et al. (2019), one of the labeled faults is “Cooling coil valve stuck (partially open - 15%)”. The “cooling coil valve” is the location, “stuck” is the behavior, and “15%” is the intensity. The symptom, or the description of anomalous behavior in the system output variables (e.g., a descriptive string), are described with time series data (e.g., reference (string) to a multidimensional array with timestamps and corresponding values). For example, Fan et al. (2024) used time-series data of common system output variables, such as air temperatures, water temperatures, flow rates, and differential pressures from fans. The fault-symptom relationships for this method subclass are the connection between faults and symptoms (e.g., a dictionary with key-value pairs) and the one to many nature of the connection (e.g., list of strings for the value in a dictionary).

For process history-based methods that do not use labeled data, the input for training the classifiers was just the symptoms themselves; the symptoms were described in a similar manner to the supervised and semi-supervised methods, with time series data (e.g., reference (string) to a multidimensional array with timestamps and corresponding values) of system output variables (e.g., a descriptive string). The output for ARM methods, like Yu et al. (2012), create rules with faults and symptoms with probability values attached. The faults for the output are described with location (e.g., a descriptive string), which is the affected system input via actuator equipment, and behavior (e.g., a descriptive string), which is the nature of the anomalous behavior. In Yu et al. (2012), one of the faults was “fan frequency is high,” which has “fan frequency” as the location, and “high” as the behavior. The fault-symptom relationships are defined by two probability values called “support” and “confidence.” Therefore, fault-symptom relationships for this method subclass require the connection between faults and symptoms (e.g., a dictionary with key-value pairs) and probability values associated with the connection (e.g., a float value).

3.2. Semantic information models

Semantic models are ways for us to represent information in a structured and standardized way that both humans and algorithms can interpret, revisit, and repurpose (Pauwels et al., 2017). Information models (semantic and information models are used interchangeably in this text) are built from (i) taxonomies, which define concepts and concept hierarchies, and (ii) ontologies, which define relationships between concepts (Malin and Throop, 2007). For our framework, we first identified information needed to be represented for FSRs, which we highlighted through a literature review of the FD methods FSR information requirements. We then searched for existing information models within and outside of HVAC and found that while many existing information models can represent partial FSR information, a complete set of descriptions may be missing.

3.2.1. FSR information within HVAC sector

We surveyed information models in the HVAC sector, such as the IFC schema, COBie, gbXML, and Brick, and found that while HVAC component information location/system input variable is well represented, fault behavior, fault severity, symptom, and FSR descriptions are incomplete.

The IFC schema has HVAC location representation (i.e., with ifcHvacDomain (HVACie)) (IFCHVACDOMAIN, n.d.), COBie can store information, such as expected fanSpeed and fanPressureDrop (COBie Guide, n.d.), and gbXML can hold system input information, such as AirLoopEquipment and equipmentType (Sun et al., 2020). These information models can store HVAC component location information at different granularities. However, they are not specifically designed for aiding FD and, therefore, do not store information about component fault behavior, fault severities, symptoms, and FSRs.

There have been efforts to extend existing information models for FD. Brick has a taxonomy for HVAC components location (i.e., sensor collection point, physical location, equipment family), but also lays the groundwork for representing symptoms and faults (Balaji et al., 2016). Symptoms exist in Brick in the form of brick:Alarm entities for specific system output variables with characteristic descriptions for certain system output variables (e.g., brick:High_Supply_Air_Temperature_Alarm). Additionally, Brick can represent time duration (e.g., brick:TimeseriesReference and brick:hasTimeseriesReference) and threshold values for some output variables (e.g., brick:Temperature_Tolerance_Parameter). The time duration Brick entity, in particular, could also be used to describe the fault’s time duration. Fault representation, on the other hand, falls short in Brick. brick:Fault_Status exists as a Brick entity, however, specific types of faults associated with specific HVAC components do not exist as entities in Brick. Furthermore, brick:Fault_Status does not indicate the behavior of the fault (e.g., is the damper stuck or leaking?) nor the severity of the fault (e.g., how badly (%) is the damper leaking?), which is useful information for facility managers who will interpret FD results and realize it into repairs in the physical system (Balaji et al., 2016) and recognized as necessary from our FD method literature review. Brick also offers tags, and more importantly, brick:fault tags, however, tags are created ad-hoc by the user (Fierro et al., 2019). Therefore, tags do not fit what we envision for FSBrick, which aims to create consistent information representation for continued revision of FSRs. Additionally, there are no formal ontological relationships in Brick to describe FSRs (e.g., brick:isPartOf, brick:isFedBy, brick:isPointOf do not convey diagnosis causal relationships).

Apart from Brick, Lawrence Berkeley National Laboratory defined common HVAC faults in a comprehensive taxonomy, where equipment type, component location, and component type, which corresponds to location/system input variable, fault behavior, and fault severity/intensity were outlined (Chen et al., 2021). However, connections with faults and their system-wide symptoms, which were not defined in a taxonomy unlike the faults, were not systematically defined, beyond in diagrams (e.g., fault trees), which again have no formal structure. Additionally, because the work focused on creating a taxonomy for common HVAC faults, symptom taxonomy and ontology were overlooked. Liu et al. (n.d.) have also tried to create an information model for aiding FD processes, which included automatic extraction of functional relationships (e.g., medium flowing in and affected by the component, import, outport, sensor associated with the component) of HVAC components necessary for inputs to FD algorithms from IFC files. However, functional relationships only hint at possible FSRs, and do not explicitly model them. In summary, taxonomy of HVAC systems and ontology for symptoms exist, but they have yet to be combined to represent FSRs.

3.2.2. FSR information outside of HVAC sector

We also surveyed outside of the HVAC domain to see if other fields have addressed supporting the representation of faults, symptoms, and FSRs, since they did not exist in the HVAC literature. In the aerospace sector, NASA has been leading the effort to move away from document-based modeling into model-based systems engineering (MBSE) with SysML as the main language used especially in FSR modeling (Mathur et al., 1998; Day et al., n.d.; Aaseng, 2015; Cornford and Feather, 2016; Izygon et al., 2016; Wang et al., 2016; Infeld et al., 2018; Figueroa et al., 2019). This body of work is especially relevant since MBSE, specifically “State Machine Diagram” and “Requirement Diagram” in SysML, allows derivation of FSRs, in the form of fault trees, failure modes and effects analysis tables, and D-matrices, in a modular fashion with expert’s intervention (Hwang et al., 2024). These diagrams, along with an algorithm to traverse them, would result in FSRs. However, NASA users do not have a unified ontology to describe the faults, symptoms, and their relationships, which is also a problem that NASA recognized and began working on through (Malin and Throop, 2007) and openCAESAR (OML Tutorials, n.d.).

The manufacturing sector also has literature on representing faults, symptoms, and FSRs (Chi et al., 2022). Xu et al. (2018) developed an ontology that describes faults through a class FaultMode and its two subclasses FaultCause, which is akin to our faults, and FaultEffect, which is akin to our symptoms, and a relationship has_reason and has_effect to describe the connections between the faults and symptoms. Similarly, Zhou et al. (2015) connected failure mode (in our case alarms) and failure cause (in our case faults) with a BecauseOf relationship. While we can learn how to represent FSRs from the manufacturing sector, the ontology for faults and symptoms is not HVAC specific. Therefore, there is still a gap to address in terms of HVAC FSR representation, which leads us to suggest that we need to create our own formal information model.

4. Architecture of FSBrick

After surveying the available information models and FD methods’ information representation needs, we moved forward with extending Brick to accommodate fault and FSRs because it already had a Resource Description Framework (RDF) format of HVAC component taxonomy to serve as a basis for fault representation and a more complete representation capability compared to other surveyed information models. RDF format is particularly beneficial for searching through all the faults, symptoms, and FSRs in the HVAC system using SPARQL queries as potential candidates for revisions required in an adaptive system, as envisioned. The Brick entities were preserved and repurposed as much as possible. Existing information models using the Brick ontology should not have issues using FSBrick since elements were added, and no existing entities or relationships were manipulated or subtracted. The tables in this section will provide piece-by-piece examples of how Brick and FSBrick entities can be combined to formulate FSR and Figure 3 will give a complete FSR example. The FSBrick Github repository contains (i) the extended Brick.ttl file and (ii) the data used for the coverage analysis in Section 5.

4.1. Representing faults

As seen in Table 1, fault behavior is not currently represented in Brick, and must be extended through the addition of FSBrick. Additionally, FSBrick must also account for new ontological relationships that will allow users to append fault severity information to the rest of the fault information.

4.1.1. Representing and connecting fault behavior

For FSBrick, we adapted the fault taxonomy developed by Chen et al. (2021, in particular, fault nature in Table 4) into the Brick ontology to account for the missing fault representation, specifically fault behavior. This work describes what behavior of faults (e.g., “Stuck”, “Leakage”) are possible for which specific HVAC component or location, which we used to create new fault entities in FSBrick. The summary of FSBrick fault representation is presented in Table 2 for faults not related to sensors or controls. The Brick entities introduced in the leftmost column in Table 2 (e.g., brick:Reheat_Valve) can be connected to these new FSBrick fault entities with a new ontological relationship fsbrick:isFault/hasFault, akin to how Xu et al. (2018) organized faults. Figure 3 shows an example implementation, and we can see that bldg:Chilled_Water_Valve is connected to fsbrick:Valve_Leakage via FSBrick relationship fsbrick:hasFault.

4.1.2. Connecting fault severities

Additionally, we used existing Brick entities to describe the fault severity with a new relationship, fsbrick:isSeverity/hasSeverity. Fault severity is described by two Brick entities: one quantity indicator to define what quantity is affected by the fault and one float value to explain to what degree the quantity is affected. For example, valves already have a Brick entity called brick:Position, which specifies in percentages what position the valve is in. The Position entity can also be connected to an XSD double via the brick:value relationship as seen in Figure 3. Rightmost column of Table 2 also gives insight into which FSBrick fault entities can be matched with existing Brick entities to describe fault severity. For example, brick:Rotational_Speed has an applicable unit “RAD-PER-MIN” which can tell us how the rotational speed has been affected due to the fsbrick:Fan_Malfunctioning.

Table 2. A snippet of fault nature taxonomy from Chen et al. (2021) for faults and how they can be combined with existing Brick entities to create new FSBrick entities for nonsensor or control-related faults

4.2. Representing symptoms

As mentioned in Section 3, Brick already has measured value/system output variable information, behavior, time duration, and threshold representation for the HVAC system. Brick already has alarms that allow for alerting operators to off-nominal conditions that correspond with common sensors found in HVAC systems. While the motivational case study showcased just one threshold-based alarm, we want to note that the Brick alarm class goes beyond solely representing symptoms for rule-based methods. The alarm class can be generalized to specify any anomalous behavior in the system. Brick has entities that allow us to define what off-nominal conditions are with parameters and setpoints, which can serve as thresholds. For example, brick:Temperature_Setpoint and brick:Temperature_Tolerance_Parameter (threshold for nominal behavior) can be connected to a brick:Air_Temperature_Alarm to imply that the alarm will sound when the monitored temperature (measured value/system output variable) reaches beyond an acceptable threshold. We selected alarms that specified the medium (air) and quantity measured (temperature) for our classification, such as brick:Air_Temperature_Alarm. For example, we can have brick:Water_Temperature_Alarm connected to brick:Chilled_Water with a brick:isPoint relationship to imply that the chilled water temperature is behaving anomalously. There is no Chilled_Water_Temperature_Alarm in Brick; Nor do we feel the need to add it to FSBrick’s entity list because the combination of entities and relationship already imbues the meaning we want.

The above representation is a specific example implementation for a qualitative model-based method symptom, however, the alarm class, as mentioned, can be generalized. The same alarm, brick:Air_Temperature_Alarm (measured value/system output variable) can be connected to a brick:TimeseriesReference with a brick:hasTimeseriesReference relationship (time duration). This alarm could also be associated with a general brick:Limit or brick:Tolerance_Parameter entity (threshold for nominal behavior), which can also have size $ {\mathrm{\mathbb{R}}}^{T\times N} $ through its connection with a time series (brick:TimeseriesReference with a brick:hasTimeseriesReference). Symptom behavior can also be implied through the comparison of the measured value/system output variable and the threshold for nominal behavior. Figure 3 illustrates these relationships with the brick:Supply_Air_Temperature_Alarm and brick:Mixed_Air_Temperature_Alarm. Therefore, we will focus more on developing the FSRs that are missing from Brick, such as the grouped and simultaneous nature of symptoms.

4.2.1. Representing grouped and simultaneous nature

In FSBrick, we created a grouped entity called fsbrick:Grouped_Symptom, which uses fsbrick:hasSymptom relationships (which will be explored in more detail in the following section) to connect individual Brick alarms to indicate the grouped nature of the symptom. The simultaneity of the individual symptom in the group would be implied through the shared time series reference start times and end times connected to each alarm entity. This extension was based off of the n-ary relations that openCAESAR (OML Tutorials, n.d.) adopted to have a “relation entity” that can hold information other than the relationship between between two entities. In Figure 3, symptoms brick:Mixed_Air_Temperature_Alarm and brick:Supply_Air_Temperature_Alarm are grouped together through the fsbrick:Grouped_Symptom entity.

Table 3. List of Brick symptoms that are connected to Brick entities to build FSRs

4.3. Representing FSRs

Lastly, although Brick does not have a system in place currently to represent fault-symptom relationships, we can borrow from the aerospace and manufacturing industry to extend FSR connection, probability, and one-to-many relation concepts to FSBrick.

4.3.1. Representing FSR connections

As explained earlier, Zhou et al. (2015) connect faults and symptoms with a BecauseOf relationship, and for FSBrick, we propose a new relationship, fsbrick:isSymptomOf/hasSymptom, to convey the same message in a more “Brick” manner (i.e., is/has ontological relationships). An example of this architecture is provided in Figure 3. A chain of entities and relationships connect the fault, fsbrick:Valve_Leakage, through fsbrick:hasSeverity, and fsbrick:hasSymptom (indirectly) to the brick:Supply_Air_Temperature_Alarm, which represents our FSR. In cases where there are no grouped symptoms, the fsbrick:hasSymptom relationship would be directly attached to the fault and the respective symptom (see Figure 4).

4.3.2. Representing and connecting FSR one-to-many relations

Similarly, we propose a new relationship to connect faults with grouped symptoms, fsbrick:isGroupedSymptom/hasGroupedSymptom. In Figure 3, bldg:Percent_Limit, which is the last element of our fault description (i.e., fault severity), is connected to the bldg:Grouped_Symptom entity with the proposed fsbrick:hasGroupedSymptom relationship.

4.3.3. Representing and connecting FSR probabilities

In the n-ary relation documentation for openCAESAR, the World Wide Web Consortium had a working page (W3C, 2006) on attaching meaning to relationships by creating a “relation entity,” which openCAESAR (OML Tutorials, n.d.) also uses. One of the suggested additional information to attach to the relation entity was a probability that describes the strength of the diagnosis certainty. Similarly, we can express the strength of the causal relationship between faults and symptoms with a brick:Quantity and Literal that ranges between 0 and 1. We can also attach this causal strength to the brick:Alarm entity to represent FSR probabilities. For example, in Figure 3, we see that brick:Supply_Air_Temperature_Alarm is attached to a brick:Quantity and a Literal through the proposed relationship fsbrick:hasSymptomProb.

Figure 3. Additions to the chilled water valve to represent fault, symptoms, and fault-symptom relationships. New entities added include fsbrick:Valve_Leakage and fsbrick:Grouped_Symptom. New ontological relationships include:fsbrick:hasFault, fsbrick:hasSeverity, fsbrick:hasGroupedSymptom, fsbrick:hasSymptom, and fsbrick:hasSymptomProb. The red box highlights fault representation and the blue box highlights symptom representation.

5. Applied study

The FSBrick architecture’s coverage (defined as % of entities mapped) was tested through surveying its ability to represent FSRs of (i) an example from the motivating case study, (ii) 3 AHUs and their BAS points, and (iii) 12 manuscripts in the FD literature. Challenges and shortcomings with the current iteration of FSBrick are also explored in this section.

5.1. FSBrick mapping in the motivating case study

We map the subsystem addition example presented in the motivating case study as an initial check for FSBrick’s coverage. In the case study, we see that the Cooling Coil Valve Stuck Open and Heating Coil Valve Stuck Closed faults both triggered the Supply Air Temperature Alarm for the existing system, consisting solely of the AHU. This FSR is recorded in Figure 4, where the Cooling Coil Valve Stuck Open fault, expressed by the chain of brick:Cooling_Valve, fsbrick:hasFault, fsbrick:Valve_Stuck, fsbrick:hasSeverity, brick:Position, brick:value, Literal:100, is connected to the symptom, brick:Air_Temperature_Alarm, with a fsbrick:hasSymptom relationship. Similar representation is also displayed for the Heating Coil Valve Stuck Closed fault and brick:Air_Temperature_Alarm symptom. For the reconfigured case where both Cooling Coil Valve Stuck Open and Heating Coil Valve Stuck Closed faults no longer display the brick:Air_Temperature_Alarm symptom, we can simply disconnect the two faults and symptom by erasing the fsbrick:hasSymptom connection as seen in Figure 5.

Figure 4. Representing the FSRs for Cooling Coil Valve Stuck Open and Heating Coil Valve Stuck Closed faults from the motivating case study before the reconfiguration.

Figure 5. Representing the FSRs for Cooling Coil Valve Stuck Open and Heating Coil Valve Stuck Closed faults from the motivating case study after the reconfiguration. The severity and alarm detail entities were taken out to avoid repetitive information.

5.2. FSBrick mapping to the FD case study in Carnegie Mellon University’s Porter Hall

Additionally, we applied FSBrick and Brick to a real-life case study using Building Automation System (BAS) points. This application was done to showcase FSBrick’s ability to represent FSRs in real-life building HVAC systems, such as the AHUs in CMU’s Porter Hall, as opposed to the simulated case study examples in the last subsection. We queried CMU’s HVAC FD platform to survey their fault database and collect nonsensor or command faults that occurred between 5/15/23 and 6/15/23. Table 4 shows the faults that were flagged by the platform’s diagnosis systems (notice that only one has a severity associated with it).

In parallel, we also pulled a subset of the available BAS points in the same 24-hour period that the faults were detected in and converted them into alarms, if an entity had setpoints and sensor values. The threshold parameters were selected to our best judgment, since the importance of the analysis is placed on representing FSRs and not the accuracy of the relationships. The alarm would ring if the following inequalities were not met for more than an hour:

• • |Outside Air Airflow—Outside Air Airflow Minimum Setpoint| < 200 cfm.

• • Outside Air damper position—Outside Air Damper minimum % open > x (varied with the 3 AHUs: AHU2 100%, AHU3 55%, AHU9 30%).

• • Exhaust Air damper position—Exhaust Air Damper minimum % open > y (varied with the 3 AHUs: AHU2 100%, AHU3 55%, AHU9 60%).

• • |PreHeat Water Supply Temperature—PreHeat Water Supply Temperature Setpoint| < 2.5 F.

• • Return Air CO₂ Maximum Setpoint—Return Air CO₂ > 0 ppm.

• • |Supply Air Static Pressure Actual—Supply Air Static Pressure Setpoint| < 0.5 in H₂O.

• • |Supply Air Airflow—Supply Air Airflow Setpoint| < 200 cfm.

• • |Supply Air Temperature Actual—Supply Air Temperature Setpoint| < 2.5°F.

Table 4. Mapping from the FD platform fault name to FSBrick and Brick entities. The dates below the AHU names correspond to the 24-hour period in which the fault was present.

The dates below the AHU names correspond to the 24-hour period in which the fault was present.

Table 5. FSR mapping for FSBrick, Brick, and BAS points from CMU. Note that the “–” holds repeating information

Out of the 3 faults, 1 fault severity, 8 symptoms, and 16 BAS points observed, we were not able to assign Brick entity for one of the symptoms (brick*:Damper_Position_Alarm does not exist, and the asterisk specifies this) and one of the BAS points (brick*:CO2_setpoint_limit does not exist). This was to bring attention to the fact that Brick itself may need to be expanded to accommodate for FSRs.

In Figure 6, we can see an example of how FSBrick, Brick, and CMU’s BAS points can be used together to represent FSRs for AHU3. To describe the Heating Valve Stuck fault, we related brick:Hot_Water_Valve to the fsbrick:Valve_Stuck entity with a fsbrick:hasFault relationship. To convey that it is a Valve Stuck Closed fault, we related a brick:Position of Literal:0 with fsbrick:hasSeverity. To describe the |Outside Air Airflow—Outside Air Airflow Minimum Setpoint| < 200 cfm symptom, we related brick:Air_Flow_Alarm to brick:Outside_Air. In addition, we attached brick:Tolerance_Parameter, brick:Min_Air_Flow_Setpoint_Limit, and brick:Air_Flow_Sensor to Literal:200, AHU3:OA Airflow Min Setpoint, and AHU3: OA Airflow respectively, to convey the alarm’s parameters. Lastly, we connected the fault with the symptom using the fsbrick:hasSymptom relationship. Along with the visualization results for AHU3, we also provided FSR representation using FSBrick, Brick, and CMU’s BAS points for all AHUs in Table 5.

Figure 6. FSR with FSBrick for AHU3’s BAS points. The connection between Brick and FSBrick entities were deleted to avoid repetition. However, all example bldg entities were named verbatim after Brick entities. bldg:Valve_Stuck and bldg*:Damper_Position_Alarm were colored by their FSBrick or Brick entity colors.

5.3. FSBrick mapping to FSRs in literature

Finally, we chose to build a database of fault behaviors, fault severities, symptoms, grouped symptoms, FSRs, and probability values for FSRs from a subset of the HVAC FD literature we surveyed previously (House et al., 2001; Liang and Du, 2007; Zhao et al., 2015; Zhao et al., 2017; Yan et al., 2018; Yan et al., 2019; Qiu et al., 2020; Taal and Itard, 2020; Li et al., 2021; Pradhan et al., 2021; Chen et al., 2023; Fan et al., 2024) and perform a coverage analysis similar to the one done for Balaji et al. (2016). In that study, Brick’s applicability and effectiveness were tested by the ability to map five campus HVAC data points (e.g., from BMS, other metadata formats, and building infrastructure) to Brick. The match percentage was calculated by field experts assessing if point names could be manually converted to a Brick entity. From the literature, we collected unique descriptors for 86 fault behaviors, 125 fault severities, 159 symptoms, 25 grouped symptoms, 98 FSRs, and 29 probability values for FSRs for nonsensor-related faults, available on a Github repository with FSBrick.ttl file. We want to mention that Fan et al.’s (2024) FSRs came from Granderson and Lin (n.d.), which provides us another opportunity to check FSBrick’s coverage for another real-life HVAC test bed. Additionally, some works in Figure 2 did not explicitly list some fault, symptom, and FSR elements; hence, they were left out of this evaluation. The results of the coverage analysis can be seen in Table 6. We will refer to this table in the following paragraphs to discuss our results.

Table 6. Percentage mapped results and sample examples for faults, fault severities, and symptoms collected from HVAC literature and fitted to FSBrick

5.3.1. Fault behavior mapping

Of the 86 fault behaviors, 88.23% of them were converted into 13 unique FSBrick fault entities. Most fault descriptors from literature were sorted into fsbrick:Valve_Stuck, fsbrick:Damper_Stuck, fsbrick:Valve_Leakage, and fsbrick:Coil_Fouling. The fall in % entities mapped came from (i) Brick missing an entity to describe ducts, and therefore, we could not account for faults like AHU duct leaking before/after supply fan and (ii) some fault descriptors were more like symptoms rather than faults. For example, heating coil reduced capacity can be due to heating coil fouling, but the authors did not specify further. Therefore, we could not conjecture what FSBrick entity would fit best.

5.3.2. Fault severity mapping

Of the 125 descriptors for fault severities, 92.8% were connected to FSBrick fault entities with 3 unique combinations of existing Brick and FSBrick ontological relationships. The unique combination consisted of a link to the FSBrick fault entity with fsbrick:hasSeverity ontological relationship to (i) brick:Flow, brick:Position, or brick:Rotational_Speed and (ii) variable quantitative descriptors (e.g., 60%) with brick:value and Literal:XSD double. Qualitative descriptions, such as exhaust air damper stuck fully open were converted to Literal:100, to the best of our knowledge. The fall in coverage came from (i) Brick missing descriptors for elements like surface area and (ii) failure to convert some qualitative descriptors (e.g., complete failure) into either FSBrick or Brick entities.

5.3.3. Symptom mapping

Of the 159 symptom descriptors, 67.9% were mapped to various alarm entities as mentioned in Table 3. The fall in mapping score came from missing entities in Brick, such as the lack of a flow alarm for water when there is one for air (i.e., brick:Air_Flow_Alarm under brick:Air_Alarm but no brick:Water_Flow_Alarm under brick:Water_Alarm). The other limitation of FSBrick and Brick was incorporating mathematical operations. For example, some of the symptoms we could not represent were Difference between return air and mixed air temperatures and Supply fan power consumption is a polynomial function of supply air flow rate. The symptoms that we had envisioned usually consisted of entities within the medium and quantity being measured. For example, the brick:Air_Temperature_Alarm associated with brick:Supply_Air would imply that the supply air is out of the range of its setpoint +/- the threshold. Therefore, it was difficult to represent House et al.’s (2001) rules that required comparison across multiple mediums. If we subtract the rules from our dataset, FSBrick reaches up to 79.8% coverage for symptoms that only concern themselves with one medium and quantity.

5.3.4. Grouped symptom mapping

We collected 25 grouped symptoms from literature, which mostly consisted of statements, such as the one in Qui et al. (2020), where an FSR says the air valve stuck fault will exhibit low room air temperature, increased fan energy consumption, and increased water pump energy consumption at the same time. If the symptom could be represented with FSBrick, the coverage result was 100% for this category. However, we want to bring attention to the fact that while the current FSBrick implementation can represent logic statements, like “AND,” it has difficulty representing others, like “OR”, and “NOT.” This is a problem that we foresee in future usages of FSBrick, although not one we encountered during our literature search.

5.3.5. FSR mapping

98 FSRs were collected, and it was possible to map all faults and symptoms with the fsbrick:hasSymptom relationship, if the subject and object of the RDF graph could be represented with Brick and FSBrick.

5.3.6. FSR probability mapping

We collected 29 FSR probabilities for the coverage analysis. Some FSRs were posterior probabilities linking faults and all symptoms together (Pradhan et al., 2021), which would mean that the fsbrick:Grouped_Symptom entity would be connected to a brick:Value Literal:XSD double with fsbrick:hasSymptomProb. Other FSRs had faults attached to individual symptoms and had probability values for these individual relationships. FSBrick represented these relationships with connections from faults to individual symptoms (e.g., alarms) via fsbrick:hasSymptom. The individual symptoms were also attached to brick:Value Literal:XSD double with the fsbrick:hasSymptomProb relationship. These two representations covered 100% of the FSRs we found in the literature.

6. Discussion and conclusion

Current FD methods do not automatically account for system reconfiguration, where existing FSRs will need to be checked and revised. To do so, we must create formal representation for existing FSRs that contain semantic information. We presented FSbrick, which was a first attempt at representing FSRs on top of an existing information model, namely Brick. We chose Brick because its development towards representing FSR was further along than other semantic models. Brick already had (i) HVAC equipment necessary for fault representation and (ii) symptoms in the form of alarms, thresholds, and setpoints. While we chose to build upon Brick for the current iteration of representing FSRs, there is merit in exploring the incorporation of this work in more commonly used schemas, like HVACie, and even graphical modeling languages, like SysML.

FSBrick adds (i) entities to describe fault behaviors (16 FSBrick entities), fault severities (2 FSBrick entities), and grouped symptoms (3 FSBrick entities) and (ii) ontological relationships to connect fault entities to symptom entities (2 FSBrick entities) and symptom entities to probability associated with the FSR (2 FSBrick entities). We conducted three studies to show FSBrick’s applicability and coverage: showcasing FSBrick’s usage on the motivational case study, applying FSBrick to represent FSRs in 3 different AHUs and their BAS points at CMU, and analyzing the % entities mapped on FSRs found in 12 FD papers across all method types. Through our analyses, we discovered that Brick itself can be extended to better accommodate for FSR representation, as it lacked infrastructure to describe some HVAC components and properties. FSBrick can also be improved further, to include mathematical and logical expression representation in symptoms and FSRs. In this iteration of this work, simultaneous alarm activation (e.g., “AND” relationship) could be represented by FSBrick with the addition of the grouped symptom entity. However, other logical expressions, such as “NOT” and “OR” could not be represented. These elements will be explored in future works to aid the automated revision of FD algorithms upon system reconfiguration.

Overall, this work is in line with the building energy academic community’s efforts to streamline the adaptation of smart analytics and control applications by standardizing descriptions for HVAC operations. FSBrick, in particular, offers an information representation approach for automating fault diagnosis. FSBrick is also the first step in creating an adaptive fault diagnosis framework robust to system reconfiguration. This framework has the potential to reduce inaccuracies in automated fault diagnosis methods deployed in commercial building HVAC systems, which will decrease energy waste and increase occupant comfort.