search

BrickSchema / Brick

Uniform metadata schema for buildings
http://brickschema.org/
BSD 3-Clause "New" or "Revised" License
290 stars 79 forks source link

Refinement of Alarm Class Categorization Structure #573

Open connorjcantrell opened 11 months ago

connorjcantrell commented 11 months ago

In our Alarm class, we have instances where our classes lead with substances (like Water or Air) as primary classifications. However, a clearer approach might be to ensure our classes are strictly based on the nature or type of potential issues, such as Leak, Temperature, Air Quality, Current, Voltage. The subsequent subclasses can then further refine with substance or specific context.

Details:

Challenge:

The process of sorting alarms into categories can get complicated, and achieving complete clarity is challenging.

Seeking Feedback:

Any insights, recommendations, or alternate approaches to enhance our Alarm classification would be greatly appreciated.

Action Class Description
Remove Cycle Alarm Short Cycle Alarm can exist independently
Remove Emergency Generator Alarm This class doesn't specify the alarm type. Emergency Generator is a specific type of generator.
Remove Emergency Alarm
Remove No Water Alarm Use "Water Low Level Alarm"
Remove Valve Position Alarm This alarm is usually associated with the difference in its feedback and its command. (See Position Feedback Alarm)
Remove Max Water Level Alarm See Water High Level Alarm
Remove Min Water Level Alarm See to Water Low Level Alarm
Remove Smoke Alarm Smoke Detection Alarm is equivalent
Remove Air Flow Loss Alarm Low Air Flow Alarm is equivalent
Remove Unit Failure Alarm Rename to Equipment Failure Alarm to stay consistent with Brick classes
Move CO2 Alarm Moved to be a subclass of Air Quality Alarm
Move Smoke Alarm Move to Air Quality Alarm
Move Supply Air Smoke Detection Alarm Move to Smoke Detection Alarm class
Add Emergency Off Alarm See G36 section 5.20.17.4.
Add Equipment Failure Alarm
Add Flow Alarm
Add Low Water Flow Alarm
Add High Water Flow Alarm
Add [Water/Oil/Refrigerant] Level Alarm Potentially add as subclasses to "Level Alarm". However it seems Alarms use the term "level" specifically for fluids
Add [Water/Oil/Refrigerant] High Level Alarm
Add [Water/Oil/Refrigerant] Low Level Alarm
Add Current Alarm
Add Return Smoke Detection Alarm
Add Supply Smoke Detection Alarm
Add Zone Smoke Detection Alarm
Add Air Quality Alarm
Add Return Air CO2 Alarm
Add Supply Air CO2 Alarm
Add Zone CO2 Alarm
Add Position Feedback Alarm
Add Valve Position Feedback Alarm
Add Damper Position Feedback Alarm
Add Change Prefilter Alarm
Add Change Final Filter Alarm
connorjcantrell commented 11 months ago

@jbkoh mentioned "Air Quality Alarm" may be too generic to be useful. I am open to hear other thoughts on how to classify alarms relating to air quality (CO2, Smoke, and others.

connorjcantrell commented 10 months ago

Context: Brick agreed the alarm class can be restructured, but wants to consider classifying alarms under distinct categories, drawing influence from the paper, Integration of FDD data to aid HVAC system maintenance. Based on this paper, I have attempted to define 3 primary categories:

Condition Based Alarm: Triggered by an instantaneous state or system status, this alarm type highlights the current situation without delving into the causative processes or potential future implications (e.g. "Leak Alarm" or "Smoke Alarm")

Behavior Based Alarm: Initiated by a series of system actions or events over a specific duration. It draws attention to an emerging trend or pattern. (e.g. "Valve Position Alarm" or "Short Cycle Alarm")

Outcome Based Alarm: Triggered when there's a deviation from established benchmarks or thresholds, emphasizing measurable outcomes without emphasizing the process leading to these outcomes. (e.g. "High Air Temperature Alarm" or "Low Air Flow Alarm")

I'd like to note the challenge involved in classifying Brick's alarm classes under these categories. Certain alarms seem to fall under more than one category, leading to potential ambiguity.

I am contemplating the possibility of combining Outcome alarms into Condition alarms. In our upcoming meeting, I propose we examine and classify the following alarms, which are debatably Condition or Outcome alarms depending on the context or viewpoint: