#817 Standardizing Fault Modeling

Cory Mosiman Tue 26 May

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.

  1. Heating
  2. Free cooling, modulating OA
  3. Mechanical + economizer cooling
  4. Mechanical cooling, minimum OA
  5. Unknown / dehumidification

Agreement Upon Conveying Occupancy

Occupancy is typically conveyed via three methods:

  1. Via a schedule
  2. Via an occupancy sensor
  3. Via an occupancy override

It is typical to have the following occupied modes:

  1. Occupied
  2. Occupied-standby
  3. 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!

Login or Signup to reply.