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., Reference Chi, Dong, Wang, Yu and Leung2022). Among inductive reasoning methods, which are bottom-up approaches that derive conclusions based on individual observations, are case-based reasoning (Xu et al., Reference Xu, Liu, Chen, Zhou and Cao2018) and knowledge-graphs (Chen et al., Reference Chen, Jia and Xiang2020; Chi et al., Reference Chi, Dong, Wang, Yu and Leung2022) (and their extension into providing causal graphs for grey-box fault diagnosis (Velibeyoglu et al., Reference Velibeyoglu, Noh and Pozzi2019; Zhu et al., Reference Zhu, Luo and He2019)). 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., Reference House, Vaezi-Nejad and Whitcomb2001; Delgoshaei and Austin, Reference Delgoshaei and Austin2017) (and their extension into providing causal graphs for bayesian networks (Zhao et al., Reference Zhao, Wen and Wang2015; Zhao et al., Reference Zhao, Wen, Xiao, Yang and Wang2017; Taal and Itard, Reference Taal and Itard2020; Pradhan et al., Reference Pradhan, Wen, Chen, Lu, Chu, Fu, O’Neill, Wu and Candan2021) and ontology-based reasoning (Zhou et al., Reference Zhou, Yu and Zhang2015; Chen et al., Reference Chen, Zhou, Liu, Pham, Zhao, Yan and Wei2015) 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., Reference House, Vaezi-Nejad and Whitcomb2001) 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., Reference Zhou, Yu and Zhang2015; faultEquipment—Xu et al., Reference Xu, Liu, Chen, Zhou and Cao2018; Fault_name—Chen et al., Reference Chen, Zhou, Liu, Pham, Zhao, Yan and Wei2015) and behavior (e.g., failureCause—Zhou et al., Reference Zhou, Yu and Zhang2015; faultCause—Xu et al., Reference Xu, Liu, Chen, Zhou and Cao2018) 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, Reference Taal and Itard2020), 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., Reference Velibeyoglu, Noh and Pozzi2019), vibration measurements (Chen et al., Reference Chen, Zhou, Liu, Pham, Zhao, Yan and Wei2015) and behavior (e.g., vibration characteristics—Chen et al., Reference Chen, Zhou, Liu, Pham, Zhao, Yan and Wei2015) are present in the symptom description.

Fault-symptom relationships were explicitly represented in qualitative model-based FD methods in various ways. House et al. (Reference House, Vaezi-Nejad and Whitcomb2001) used a table with faults and symptoms on the axes with check marks to indicate the relationships between them, Zhu et al. (Reference Zhu, Luo and He2019) used graphical representation of arrows in between faults and symptoms with probability values associated with them, and Zhou et al. (Reference Zhou, Yu and Zhang2015), Chen et al. (Reference Chen, Zhou, Liu, Pham, Zhao, Yan and Wei2015), and Xu et al. (Reference Xu, Liu, Chen, Zhou and Cao2018) 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., Reference Venkatasubramanian, Rengaswamy, Yin and Kavuri2003). 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., Reference Qiu, Yan, Deng, Liu, Shang and Wu2020), (ii) state observers and also input observers (Zhang et al., Reference Zhang, Li, Cabassud and Dahhou2017; Naderi and Khorasani, Reference Naderi and Khorasani2018; Yan et al., Reference Yan, Luh and Pattipati2018), (iii) frequency domain residuals (Frisk, Reference Friskn.d.), and (iv) parameter estimation (Isermann, Reference Isermann2005; Turner et al., Reference Turner, Staino and Basu2017).

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, Reference Friskn.d.; Xu and Zhang, Reference Xu and Zhang2004; Qiu et al., Reference Qiu, Yan, Deng, Liu, Shang and Wu2020):

(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. (Reference Qiu, Yan, Deng, Liu, Shang and Wu2020) 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. (Reference Yan, Luh and Pattipati2018) 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., Reference Jain, Poon, Singh, Spanos, Sanders and Panda2019), 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., Reference Venkatasubramanian, Rengaswamy, Yin and Kavuri2003; Frisk, Reference Friskn.d.; Svärd, Reference Svärdn.d.). These influence structures are tables, much like the one used by House et al. (Reference House, Vaezi-Nejad and Whitcomb2001), 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, Reference Mirnaghi and Haghighat2020). Supervised methods, such as ones that use support vector machines (SVMs) or Neural Networks (NN) (Yan et al., Reference Yan, Ji, Lu, Huang, Shen and Xue2019), 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., Reference Li, Cheng, Cai, Zhang and Cai2021), active learning (Fan et al., Reference Fan, Wu, Zhao and Mo2024), and similarity learning (Chen et al., Reference Chen, Xiao and Guo2023) 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., Reference Yu, Haghighat, Fung and Zhou2012).

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. (Reference Yan, Ji, Lu, Huang, Shen and Xue2019), 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. (Reference Fan, Wu, Zhao and Mo2024) 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. (Reference Yu, Haghighat, Fung and Zhou2012), 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. (Reference Yu, Haghighat, Fung and Zhou2012), 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.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., Reference Sun, Hu, Gowri and Xu2020). 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., Reference Balaji, Bhattacharya, Fierro, Gao, Gluck, Hong, Johansen, Koh, Ploennigs, Agarwal, Berges, Culler, Gupta, Kjærgaard, Srivastava and Whitehouse2016). 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., Reference Balaji, Weibel and Agarwal2016) 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., Reference Fierro, Koh, Agarwal, Gupta and Culler2019). 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., Reference Chen, Lin, Crowe and Granderson2021). 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. (Reference Liu, Akinci, Garrett and Bergésn.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., Reference Mathur, Deb and Pattipati1998; Day et al., Reference Day, Donahue, Ingham, Kadesch, Kennedy and Postn.d.; Aaseng, Reference Aaseng2015; Cornford and Feather, Reference Cornford and Feather2016; Izygon et al., Reference Izygon, Wagner, Okon, Wang, Sargusingh and Evans2016; Wang et al., Reference Wang, Izygon, Okron, Garner and Wagner2016; Infeld et al., Reference Infeld, Goggin, Vipavetz and Grondin2018; Figueroa et al., Reference Figueroa, Walker and Underwood2019). 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., Reference Hwang, Akinci and Berges2024). 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, Reference Malin and Throop2007) and openCAESAR (OML Tutorials, n.d.).

The manufacturing sector also has literature on representing faults, symptoms, and FSRs (Chi et al., Reference Chi, Dong, Wang, Yu and Leung2022). Xu et al. (Reference Xu, Liu, Chen, Zhou and Cao2018) 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. (Reference Zhou, Yu and Zhang2015) 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.1.1. Representing and connecting fault behavior

For FSBrick, we adapted the fault taxonomy developed by Chen et al. (Reference Chen, Lin, Crowe and Granderson2021, 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. (Reference Xu, Liu, Chen, Zhou and Cao2018) 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. (Reference Chen, Lin, Crowe and Granderson2021) 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.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.1. Representing FSR connections

As explained earlier, Zhou et al. (Reference Zhou, Yu and Zhang2015) 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.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 (Reference House, Vaezi-Nejad and Whitcomb2001) 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. (Reference Qiu, Yan, Deng, Liu, Shang and Wu2020), 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., Reference Pradhan, Wen, Chen, Lu, Chu, Fu, O’Neill, Wu and Candan2021), 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.