FSBrick: An information model for representing fault-symptom relationships in HVAC systems

Current fault diagnosis (FD) methods for Heating, Ventilation, and Air Conditioning (HVAC) systems do not accommodate for system reconfigurations throughout the systems’ operational 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 explicitly or implicitly. We motivate the need to represent FSRs by illustrating their changes when the system reconfigures. Then, we survey existing efforts to represent FSRs within the HVAC sector and adjacent fields, and choose to extend Brick. 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 7 FD method papers, and find that FSBrick can represent 88.2% of faults, 87.7% of fault severities, and 72.5% of symptoms. The analyses show that both Brick and FSBrick should be expanded further to cover HVAC component and property information, and mathematical and logical statements used to formulate FSRs in real life and literature. 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 FD algorithms upon system reconfiguration.


INTRODUCTION
Faults in Heating, Ventilation, and Air Conditioning (HVAC) systems account for 20% of energy consumption in buildings [12] which corresponds to approximately 2.4% of the total annual energy use of the United States, equivalent to approximately 2.4 quadrillion BTUs [13].However, detecting and diagnosing these faults have 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 [23].
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) [17], lists known fault and symptom pairs (explicitly), and supervised learning methods listed in [27] learn a function that maps symptoms to known faults (implicitly).These fault-symptom relationships (FSR) can change as a result of system reconfiguration [18] (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 [18], 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 [29,30,32,33,[37][38][39]41].The process history-based methods require labeled data to train classification functions for the new system configuration [27,36].
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 needs to be developed to conjecture how a change in the system configuration will affect the FSR.Towards this vision, we 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 will be 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 existing information models and how they fall short in representing 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 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) 7 FD papers (Section 5).Finally, we have a summary of findings from the analyses and a discussion for future improvements (Section 6).

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 [5,6,16,22].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).
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., [17,37]) 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 [2].
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  ) 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 [17].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.

LITERATURE REVIEW
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 [28].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 [25].For our framework, we first identified information needed to be represented for FSRs, which include HVAC components, component faults, fault severities, system symptoms, and FSRs themselves.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.

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 is well represented, fault, fault severity, symptom, and FSR descriptions are incomplete.
The IFC schema has HVAC component representation (i.e., with ifcHvacDomain (HVACie)) [19], COBie can store information, such as expected fanSpeed and fanPressureDrop [9], and gbXML can hold input information, such as AirLoopEquipment and equipmentType [31].These information models can store HVAC component information at different granularities.However, they are not specifically designed for aiding FD and, therefore, do not store information about component faults, fault severities, system-wide symptoms, and FSRs.
There have been efforts to extend existing information models for FD.Brick has a taxonomy for HVAC components (i.e., sensor collection point, physical location, equipment family), but also lays the groundwork for representing symptoms and faults [3].Symptoms exist in Brick in the form of brick:Alarm entities (e.g., brick:High_Supply_Air_Temperature_Alarm).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 nature 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 [4].Brick also offers tags, and more importantly brick:fault tags, however, tags are created adhoc by the user [14].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).
Apart from Brick, Lawrence Berkeley National Laboratory defined common HVAC faults in a comprehensive taxonomy, where equipment type, component location, component type, and fault nature were outlined [7].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.[24] has 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.

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, fault severities, 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 [1,10,11,15,20,21,26,34].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 [18].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 [25].
The manufacturing sector also has literature on representing faults, symptoms, and FSRs [8].[35] 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, [40] 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 are 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.

ARCHITECTURE OF FSBRICK
After surveying the available information models, we moved forward with extending Brick to accommodate fault and FSRs because it already had (i) a Resource Description Framework (RDF) format of HVAC component taxonomy to serve as a basis for fault representation and (ii) a taxonomy of symptoms, compared to the other HVAC information models which only had one of the above.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 2 will give a complete FSR example.The FSBrick Github repository contains (i) the extended Brick.ttlfile and (ii) the data used for the coverage analysis in Section 5.

Representing faults
For FSBrick, we adapted the fault taxonomy developed by [7] [35] organized faults.Figure 2 shows an example implementation, and we can see that bldg:Chilled_Water_Valve is connected to fsbrick:Valve_Leakage via FSBrick relationship fsbrick:hasFault.

Representing fault severities
Additionally, we used existing Brick entities to describe the fault severity with a new relationship, fsbrick:isSeverity/hasSeverity.Fault severities are minimum thresholds needed for the FSRs to hold true.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 2. Table 1's rightmost column 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.

Representing symptoms
As mentioned in the Literature Review section, 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.However, the scope of this paper will focus mostly on threshold-based alarms.Brick has entities that allow us to define what off-nominal conditions are with parameters and setpoints.For example, brick:Temperature_Setpoint and brick:Temperature_Tolerance_Parameter can be connected to a brick:Air_Temperature_Alarm to imply that the alarm will sound when the monitored temperature 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.Therefore, we will focus more on developing the FSRs that are missing from Brick.

Representing FSRs
As explained earlier, [40], connects 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 2 below.A chain of entities and relationships connect the fault, fsbrick:Valve_Leakage, through fsbrick:hasSeverity, and fsbrick:hasSymptom to the brick:Air_Temperature_Alarm, which represents our FSR.

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) 7 manuscripts in the FD literature.Challenges and shortcoming with the current iteration of FSBrick are also explored in this section.

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 We queried CMU's HVAC FD platform to survey their fault database and collect non sensor or command faults that occurred between 5/15/23 to 6/15/23.Table 3 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    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 5, 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 4.

FSBrick mapping to FSRs in literature
Finally, we chose to build a database of faults, fault severities, symptoms, and FSRs from a subset of the HVAC FD literature we surveyed previously [29,30,32,[36][37][38][39] and perform a coverage analysis similar to the one done for [3].In that study, Brick's applicability and effectiveness was 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 51 faults, 73 fault severities, 69 symptoms, and FSRs for non-sensor related faults, available on a Github repository with FSBrick.ttlfile.The results of the coverage analysis can be seen in Table 5.We will refer to this table in the next 4 paragraphs to discuss our results.
Of the 51 faults, 88.2% of them were converted into 24 unique FSBrick fault entities.Most fault descriptors from literature were sorted into fsbrick:Valve_Stuck, fsbrick:Damper_Stuck, fsbrick:Fan_Malfunctioning, and fsbrick:Filter_Block.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.
Of the 73 descriptors for fault severities, 87.7% 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.
Of the 69 symptom descriptors, 72.5% were mapped to various alarm entities as mentioned in Table 2.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.
We did not conduct coverage tests on FSRs, because intuitively, we would be able to map these relationships for all fault and symptom entities that have representation in Brick or FSBrick.However, some exceptions arose with respect to representing logic statements like 'AND', 'OR', and 'NOT'.For example, [30] has an FSR that says that 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.The current FSBrick implementation can convey the connection between faults and symptoms, but it fails to capture additional meanings, such as the simultaneous activation of three alarms indicating another specific symptom.

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 contains 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 of its development towards representing FSR was further along than other semantic models.Brick already had (i) HVAC locations 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.Furthermore, in this paper, we chose to focus on thresholdbased alarms, commonly used for rule-based methods, but in the future, we can extend the representation to encompass symptoms for all FD method classes.FSBrick adds (i) entities to describe faults and fault severities and (ii) ontological relationships to connect fault entities to symptom 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 7 FD papers.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.For example, simultaneous alarm activation (e.g., 'AND' relationship) cannot be represented by FS-Brick yet.These elements will be explored in future works to aid the automated revision of FD algorithms upon system reconfiguration.

Figure 2 :Figure 3 :
Figure 2: Additions to the chilled water valve to represent fault, specifically fault nature and severity, with new ontological relationships fsbrick:hasFault and fsbrick:hasSeverity and new entities fsbrick:Valve_Stuck.To represent FSRs, we added ontological relationship fsbrick:hasSymptom to connect existing symptom representation in Brick with the new fault representation

Figure 4 :
Figure 4: 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

Figure 5 :
Figure 5: 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 (Table 4's Fault Nature in particular) into the Brick ontology to account for the missing fault representation.This work describes what nature of faults (e.g., 'Stuck', 'Leakage') are possible for which specific HVAC component, which we used to create new fault entities in FSBrick.The summary of FSBrick fault representation is presented in Table 1 for faults not related to sensors or controls.The Brick entities introduced in the leftmost column in Table 1 (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 FSBrick mapping to the FD case study in Carnegie Mellon University's Porter HallAdditionally, 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.
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 3 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 4.5.2

Table 1 :
[7]nippet of fault nature taxonomy from[7]for faults and how they can be combined with existing Brick entities to create new FSBrick entities for non sensor or control related faults.

Table 2 :
A list of Brick symptoms that are connected to Brick entities to build FSRs 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

Table 3 :
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 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

Table 4 :
FSR mapping for FSBrick, Brick, and BAS points from CMU.Note that the '-' holds repeating information

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