Modeling Meters with Brick

[Malte Schwerin]

Hey, I am very new to Brick and already seem to have some problems with basic understanding. My task is to model a simple sample building with an electricity meter, gas meter, and water meter. I found correspnding classes for these, but what confuses me

 is that the documentation only lists the relationship "regulates" for them. From my understanding I would have expected a "measures" relationship.

What also confuses me is how a Meter should interact with a sensor. For electricity, I found the "Electrical_Power_Sensor", which also has the "measures" relationship I expected for the Meters. However, there seems to be no corresponding sensor for water or gas flow, right? How should I model these Meters and eventually link them to timeseries data I might have for them?

Unfortunately, I could not find any examples or detailed descriptions for my use case. Maybe what I'm trying to do is not the intended way at all? I would be really grateful for any clarifications or hints to examples.

[Ambuj Shatdal]

I agree that we need more clarity and examples to model Meters (and their corresponding sensors, when applicable).

Brick does have the “equipment” (the physical entity) of Meters further specialized as Gas Meter, Electrical Meter, and Water Meter.

In general, however, Brick likes to model producers and consumers of data as “points”. Brick does have a “Usage Sensor” concept but it doesn’t quite line up with the meters except for Water Usage Sensor. Energy Usage Sensor sensor is generic enough and can potentially be used for both Gas and Electricity. But there is an another class of Power Sensor that seems to have some similar implication.

I think it would be nice to have a clean 1:1 matching between the meters and the sensors. We’ll open a pull request and discuss this in our upcoming working/technical group discussions and you are welcome to participate.

Ambuj

--
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/b83af5c3-b65b-452f-9727-37127240f609n%40googlegroups.com.

[Gabe Fierro]

Hi Malte:

Thanks for reaching out!

To add onto what Ambuj has pointed out, we currently have some new features on the ontology documentation page under development, which should hopefully clear up some of the ambiguity. Creating examples for common scenarios is also something we are actively working on. I took some time to put together a simple example of how a building electrical meter might be modeled in Brick: https://gist.github.com/gtfierro/18f8943abd2c42516a8771b4f19e1e60 . This contains how the relationship between the meter (an equipment) and the sensors (the data sources) is captured, and how identifiers/primary keys for those timeseries data streams can be modeled. I would recommend checking out some of the developer documentation that we have written at https://docs.brickschema.org/intro.html, which has some more helpful information.

Hope this is helpful! Please don't hesitate to ask further questions or let me know if anything is ambiguous or unclear

Best,

Gabe

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/2C0966E6-A546-4854-A925-CD32ACA8984C%40yahoo.com.

[Gabe Fierro]

Hi Malte:

We have weekly working group meetings focusing both on ontology development and tooling development; you can see the working group schedule on a Google calendar (link here). It would be great to have you as a participant! We can also continue the discussion asynchronously on this email thread.

The intent of the current meter/sensor divide is to model the data coming out of the physical/virtual meter separately from that meter's position in some submetering hierarchy. Under this model, the quantity that is being metered (e.g. gallons, kBTU, peak demand, etc) should be represented by the sensor. (In Brick, a sensor is the data source, not the physical sensing device). The energy usage sensor seems appropriate for both electricity and gas meters, but maybe there is something I'm missing? Would you be able to describe a little more about what kinds of sensors make sense to be associated with those meters?

Best,

Gabe

On Thu, Apr 29, 2021 at 6:52 PM Malte Schwerin <malte.s...@eonerc.rwth-aachen.de> wrote:

Hey Gabe and Ambuj,

thanks for the example! This is exactly what I needed. As Ambuj said, there is still the problem that there is no 1:1 matching between meters and sensors. For electricity, I could also use a  energy usage sensor , right? This might be more consistent with gas and water meters, as I could also use a energy usage sensor for gas and a water usage sensor for water.

I would be very happy to participate in your discussions about this topic.

Best,

Malte

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/43360aa1-8fe7-4455-98b4-ae1dae65aa39n%40googlegroups.com.

[Gabe Fierro]

Hi Morris:

We do have a basic building meter example that is on the Brick repository: https://github.com/BrickSchema/Brick/blob/master/examples/building_meter/building_meter.ttl . Properties like the power phase are captured as entity properties rather than as subclasses. We have quantities for voltage/current imbalance defined, but not yet the Points for them (though I've created an issue to track their creation: https://github.com/BrickSchema/Brick/issues/292).

Let me know if the example makes sense and if there's any additional information I can provide. I would be happy to augment the example Building Meter on the Brick GitHub with more attributes/points/properties if you can describe what you'd like to see.

Best,

Gabe

On 7/3/21 10:10 PM, Morris Chen wrote:

Hey, 

I am also a new guy to Brick  and also trying to build up data model for digital electrical power meter in our building.

There are a lot of data, such as power factory A, power factory B, power factory C, Active Power Total, Reactive Power Total, ..., .etc,  in an electrical power meter. how can I put them into brick model? do I need to create another class for those? 

For example, 

1. create class Active_Power_A_Sensor nuder brick:Active_Power_Sensor

2. create class Voltage_Unbalance_Sensor under brick:Voltage_Sensor

3. create class Voltage_Unbalance_Sensor under brick:Voltage_Unbalance_Sensor

...

or any other way to build up those data points into brick?

 

P.S. here(http://www.toyotech.com.tw/upload/pdf/Sch-PM5350rs485.pdf) is pdf for Schneider power meter

Many Thanks

BR,

Morris

gt.f...@berkeley.edu 在 2021年5月4日 星期二上午6:23:14 [UTC+8] 的信中寫道：

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/86383621-3202-4250-9592-77a642d52d33n%40googlegroups.com.

[Gabe Fierro]

Hi Oskar:

Thanks for the questions! We've proposed a couple designs in the past, but it has been discussed that there is a need to make this much more straightforward to model and to provide examples.

I usually have the devices "brick:feeds" the meter equipment, and then associate the energy/power sensors with the meter. One can then have "brick:feeds" describe the submeter hierarchy. We may want a specialized relationship to address these different scenarios however: maybe one relationship to indicate that the electrical power/energy consumption is measured by a meter, and another to indicate how meters relate to one another. Do you have some examples of the kinds of hierarchies you'd like to model?

Best,

Gabe

On Mon, Nov 8, 2021 at 4:23 PM Oskar Nilsson <oskarni...@gmail.com> wrote:

Hi,

This has been discussed in other places but not sure if there is a consensus:

1. How do you associate a meter with what is consuming/producing the energy (e.g. a chiller, a floor or a domestic hot water system)?
2. Is there a way to model submetering hierarchies?

Thanks
Oskar

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/31a7526a-3a96-470b-8d73-376c752c2df3n%40googlegroups.com.

[Steve Ray]

Gabe,

Just thought I'd remind you that ASHRAE 201 models meters and submeter hierarchies, so you might want to keep alignment with that in mind.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/CAFJ%2Bac%3Dn9jh6usCXpW3X%2BuT%3DWH-CfJ65%3DHBnzTgJQEiOKWk5-w%40mail.gmail.com.

[Gabe Fierro]

Thanks for the pointer, Steve! I think alignment with 201 would be a great feature.

I am reading through 201 and as far as I can tell the submeter hierarchy is modeled with a "partOf" relationship between the meter devices --- do I have this right? I am trying to figure out what software I can use to open the UML diagrams on LInux, but I'm curious if there are any reference models or examples that might elucidate how 201 models meters and submeter hierarchies?

Best,

Gabe

[Steve Ray]

Gabe,

You can explore FSGIM using either:

https://github.com/steveraysteveray/fsgim-owl for OWL, and

https://github.com/steveraysteveray/fsgim-shacl for SHACL

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/8ce4b69a-dee0-7198-ff09-b0861aa49957%40cs.berkeley.edu.

[Oskar Nilsson]

A thought about energy usage. It’s good that one can capture what loads are associated with a meter using relations but for energy reporting purposes it may be beneficial to also somehow expand the meter subclasses with usages. Usages such as: air conditioning, heating, ventilation, domestic hot water, office equipment, etc. Or is there a better way to capture this consistently?

[Gabe Fierro]

Hi everyone:

I wanted to point you all towards the pending documentation on the Meter model for v1.3.0 (https://github.com/BrickSchema/docs/blob/d2609216699679902fe54b90d31c8c4edc25a75d/modeling/meters.md) as well as the changes to Brick itself (https://github.com/BrickSchema/Brick/pull/363).

Oskar, to your question: I think the best way to achieve that would be to associate a meter with one of the Brick System classes, and then place equipment/spaces inside that system instance with the "isPartOf" relationship.

Best,

Gabe