Points in model design

98 views
Skip to first unread message

Matias Ekkerhaugen

unread,
Nov 10, 2023, 7:22:49 AM11/10/23
to Brick User Forum (Unified Building Metadata Schema)
Hi, I have a question regarding modelling of point classes.

Let's say I have a Temperature Sensor on an AHU, located between a Filter and a Supply Fan. Additionally I may have a Low Temperature Alarm and a Min Limit associated with this Temperature Sensor, such that the alarm goes off it the temperature drops below the min limit.

So far I have been modelling this as follows:
AHU-hasPoint->Temperature Sensor
AHU-hasPoint->Low Temperature Alarm
AHU-hasPoint->Min Limit
AHU-hasPart->Filter
AHU-hasPart->Supply Fan

I am facing two challenges/problems with this approach:
  1. It is not valid brick to express that (Filter)-feeds->(Temperature Sensor)-feeds->(Supply Fan) and I have not managed to figure out how such a relationship could be expressed in brick.
  2. What would be the correct way to express that Temperature Sensor, Low Temperature Alarm and Min Limit "belong together"?
Can anyone shed some light on these two challenges that I am facing? What would be the "correct" way to model this case?

Chris Bupp

unread,
Nov 14, 2023, 8:45:37 AM11/14/23
to Brick User Forum (Unified Building Metadata Schema)
I'm working on similar attempt to model alarms, and was planning on capturing the alarm configuration. I've created a DRAFT PR on the RealEstateCore github: https://github.com/RealEstateCore/rec/pull/250

An analog input alarm can have these additional configurations:
- high limit
- low limit
- deadband
- time delay
- limit enabled
- event enabled

The BrickSchema classes, seem to me like they'd want to represent the point's alarm configuration using 7 twins. I'm tempted for my implementation to extend the Alarm class to have a single class that captures:

1. the point's alarm configuration
2. the exception event
3. ACK events

Chris Bupp

unread,
Nov 14, 2023, 10:04:58 AM11/14/23
to Brick User Forum (Unified Building Metadata Schema)
I didn't answer your question...

I think you're correct modeling this:

AHU-hasPoint->Temperature Sensor
AHU-hasPoint->Low Temperature Alarm
AHU-hasPoint->Min Limit
AHU-hasPart->Filter
AHU-hasPart->Supply Fan

In REC's implementation of the BrickSchema Alarm, an ExceptionEvent was created to capture the lastKnownValue of the Alarm. A relationship was added called "sourcePoint" to capture the relationship between the alarm and the point that caused the alarm. I don't see that relationship in BrickSchema.

I also don't see a way to group the min limit, low temperature alarm, or temperature sensor. This is why I'm tempted to move to specific extensions. For example, instead of  "Low Temperature Alarm", I would create something like:

Alarm:
- sourcePoint
- lastKnownValue <string> (the message of the alarm)
- fromState <enum>
- toState <enum>
- isEnabled <boolean>

AnalogInputAlarm (extends Alarm)
- timeDelay <int>
- timeDelayNormal <int>
- isHighLimitEnabled <boolean>
- isLowLimitEnabled <boolean>
- highLimit <float>
- lowLimit <float>
- deadband <float>

You would be able to infer that the AnalogInputAlarm was a low temperature alarm by it's relationship (analogInputAlarm-sourcePoint->Temperature Sensor) and that it has lowLimit and isLowLimitEnabled==true.

Gabriel Fierro

unread,
Nov 16, 2023, 5:05:39 PM11/16/23
to Chris Bupp, Brick User Forum (Unified Building Metadata Schema)

Hi Matias:

 

Thanks for the question!

 

Sensors, alarms, etc in Brick are Points, so they model the BMS I/O entity, not the physical sensor. We are looking into modeling these kinds of “sensor platforms”, which would be able to host multiple points. I believe there’s a partial PR for creating such “sensor platform” or “sensor equipment” but the details haven’t been worked out yet. I’ve been busier than I expected teaching this semester so I should get to this in December; it should be fairly similar to the concepts already in SSN/SOSA. I’m thinking to create it as a subclass of “IT EQuipemnt” and that should be enough – it can always be specialized further for specific sensor platforms.

 

We don’t have a good answer on grouping points/alarms/etc yet. There is an emerging ontology based on the ASHRAE 231 standard which can express control logic, but this is probably more than we want. You can look at https://github.com/BrickSchema/Brick/issues/393 and https://github.com/BrickSchema/Brick/issues/573 for some of the ongoing conversatiosn around alarms. We would love another perspective!

 

Another related discussion is how to standardize enumerations for things like commands, states, and alarm enums. This conversation (https://github.com/BrickSchema/Brick/issues/566) captures some of what we’re thinking. Look out for some emerging developments on the Brick mailing list!

 

I also want to pitch the working groups (https://brickschema.org/blog/working-groups/) which you can always attend if you’d like to speak with me directly! They are at different times/days so hopefully its possible to find one that works for you regardless of timezone

 

Best,

Gabe

 

--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/70c915de-94d2-4959-a072-7aaeff6ca783n%40googlegroups.com.

Matias Ekkerhaugen

unread,
Dec 22, 2023, 9:55:20 AM12/22/23
to Brick User Forum (Unified Building Metadata Schema)
Hi and thank you both for your answers,

I am sorry that I have not responded to this discussion until now. First of all, your answers serve as a confirmation that there does not seem to be anything crucial that I have missed. I think your suggestion Gabe to introduce "sensor platforms" or "sensor equipments" is a good idea. This is the kind of solution that we have been discussing internally as well when thinking about how to address the challenges that we are facing regarding this problem. Thank you also for the invitation to the working groups! We might suddenly appear at one of them.

Merry Christmas,
Matias
Reply all
Reply to author
Forward
Message has been deleted
0 new messages