Curious as to people's thoughts on coming up with a proposal for modeling "faults". In general, most faults implemented consist of simple rule sets. Furthermore, many of these rule sets are consistent across vendors / implementers, although may have different names.
Having a standardized mechanism and definition for modeling faults would be very helpful for interoperability of different vendor applications communicating with one another, specifically since tools with fault engines / reporting engines / dashboarding engines are not always the same.
There are many different aspects to this conversation, including what is the scope of fault types we want to tackle (rules-based, black-box, etc.), how we need to represent the faults and expose the varying parameters, etc.
In an attempt to not boil the ocean, at this point in time, I'm thinking specifically about modeling of faults for AHUs, from which our definitions can stem from those proposed by the following:
Making sure we are in alignment with CA Title 24 definitions, Section 120.2(i)(7)
ASHRAE G36 faults
Anyways, I wanted to put the feelers out to see who all else is interested in contributing, whether or not there are other existing efforts we should be aware of, and even whether this is in the scope of Haystack.
From a workplan perspective, I think we would need to do the following:
Agreement Upon Operating States
First, I think we need to standardize on how exactly different equipment modes are defined / inferred. In the paper above (and in G36), there are four or five modes / operating states (OS) for air-handling units.
Heating
Free cooling, modulating OA
Mechanical + economizer cooling
Mechanical cooling, minimum OA
Unknown / dehumidification
Agreement Upon Conveying Occupancy
Occupancy is typically conveyed via three methods:
Via a schedule
Via an occupancy sensor
Via an occupancy override
It is typical to have the following occupied modes:
Occupied
Occupied-standby
Unoccupied
Simply fleshing out the details of expected set points / modes using occupancy and operating states would be important for standardizing on faults, and something that shouldn't be overly burdensome.
Initial Thoughts
As a very simple proposal example, we could use the tagset of {faultType:APAR-25 fault point} where faultType is a new tag with a standardized set of potential enumerations stemming from the ID of something defined externally, something like:
[
{"id": "APAR-25",
"dis": "Discharge air sensor consistently out of bounds",
"longDescription": "Explanation ...",
"equation": "Some way to define an equation...",
"operatingStates": ["Mode-1", "Mode-2", ...],
"occupancyStates": ["Occupied", "Standby"],
"pointsRequired": [{discharge air temp sensor point}, {discharge air temp sp point}, {error bound...(not sure about this one)}]
}, {}, ..., {}
]
Anyways, please feel free to respond back with questions, thoughts, additional items for consideration, etc. Thanks!
Cory Mosiman Tue 26 May 2020
Hey Haystack Community,
Curious as to people's thoughts on coming up with a proposal for modeling "faults". In general, most faults implemented consist of simple rule sets. Furthermore, many of these rule sets are consistent across vendors / implementers, although may have different names.
Having a standardized mechanism and definition for modeling faults would be very helpful for interoperability of different vendor applications communicating with one another, specifically since tools with fault engines / reporting engines / dashboarding engines are not always the same.
There are many different aspects to this conversation, including what is the scope of fault types we want to tackle (rules-based, black-box, etc.), how we need to represent the faults and expose the varying parameters, etc.
In an attempt to not boil the ocean, at this point in time, I'm thinking specifically about modeling of faults for AHUs, from which our definitions can stem from those proposed by the following:
Anyways, I wanted to put the feelers out to see who all else is interested in contributing, whether or not there are other existing efforts we should be aware of, and even whether this is in the scope of Haystack.
From a workplan perspective, I think we would need to do the following:
Agreement Upon Operating States
First, I think we need to standardize on how exactly different equipment modes are defined / inferred. In the paper above (and in G36), there are four or five modes / operating states (OS) for air-handling units.
Agreement Upon Conveying Occupancy
Occupancy is typically conveyed via three methods:
It is typical to have the following occupied modes:
Simply fleshing out the details of expected set points / modes using occupancy and operating states would be important for standardizing on faults, and something that shouldn't be overly burdensome.
Initial Thoughts
As a very simple proposal example, we could use the tagset of
{faultType:APAR-25 fault point}wherefaultTypeis a new tag with a standardized set of potential enumerations stemming from the ID of something defined externally, something like:[ {"id": "APAR-25", "dis": "Discharge air sensor consistently out of bounds", "longDescription": "Explanation ...", "equation": "Some way to define an equation...", "operatingStates": ["Mode-1", "Mode-2", ...], "occupancyStates": ["Occupied", "Standby"], "pointsRequired": [{discharge air temp sensor point}, {discharge air temp sp point}, {error bound...(not sure about this one)}] }, {}, ..., {} ]Anyways, please feel free to respond back with questions, thoughts, additional items for consideration, etc. Thanks!