Meter aggregation: is brick:feeds appropriate?

[Dan Hugo]

Hi all, 

I would like to raise a conversation about convention: can / should 'brick:feeds' be used to aggregate hierarchical meters? If so, how? If not, then how should we express sub-metering? A cursory look through this forum didn't turn up a solution. 

Scenario: I am attempting to model a hierarchy of power meters in a research building with offices and laboratories. There is a main power meter, 3 tiers of sub-meters, and various equipment. What a want to be able to do is express that power_meter_1 aggregates the sum of powers measured by power_meter_2, power_meter_3 ... power_meter_n, which in turn aggregate power from other meters/equipment, etc. 

I assumed that I could use 'brick:feeds', so that :power_meter_1 brick:feeds power_meter_2 , power_meter_3 ... ; This neatly expresses the flow of energy through meters without modelling electrical busses, fuses, switches etc. 

However, the lowest level in this hierarchy is an AHU (reporting its own power consumption), which also feeds air to other equipment (eg VAVs). If I later write a simple sparql query with "?x brick:feeds* ?vav .", expecting to find equipment that feed air to a VAV, then I will inadvertently find that the main POC energy meter is feeding my VAVs, which is clearly wrong! I would have to constrain by parent class to find only HVAC equipment, but that is pushing more implicit knowledge onto the user/application trying to interrogate my model. It gets even messier once we start to consider that one piece of equipment may feed/be-fed-by multiple different substances other than just air. 

I notice that the 1.1 RC has brick:feedsAir. This looks very useful, but leaves me with a couple of questions. 

1. Will there be other brick:feedsX sub-properties of brick:feeds for other things? 
2. If we use brick:feeds for sub-metering, which direction? What I mean is this: the energy/water/gas is physically travelling from utility POC towards equipment, but the measured values are numerically travelling from equipment back towards the utility POC. 
3. Should we actually consider the requirement for a brick:aggregates property, so that sub-metering can be adequately expressed in brick models? 

I would be grateful for any comments or suggestions from the team and community about how to handle this. :) 

Thanks, and regards, 
Daniel Hugo. 

[Jason Koh]

Hi Dan,

An interesting and important idea. I think using the plain feeds is not appropriate for data aggregation. A couple of possible solutions:

1. Yes, feedsXXX is totally fine. Introducing feedsData might be the closest solution to your suggestion. E.g., meter_2 feedsData meter_1. The complication is, as you said, it may be convoluted with other `feeds` usage. Though I don't see a big problem with it, we have an existing implementation already as described below.

2. `controls` dictates what you wanted to model. It is used when a point's values are an input to the control logic determining another point's value. For example,

:supply_air_flow_sensor_1 brick:controls :damper_command_1.

:supply_air_flow_setpoint_1 brick:controls :damper_command_1.

because damper_command_1's value is determined or controlled by the other two points.

Though meters are not controllers or actuators, assuming meter_1's value is determined by meter_2 and meter_3, meter_2 controls meter_1 and meter_3 controls meter_1 logically makes sense to me. We have not heavily used `controls` so far because it's hard to get such relations easily from existing buildings, but I think submetering is a good example.

3. If those meters independently measure the different levels of energy usage, we can specify what each meter measures exactly. meter_1 measures presumably the entire building (I said "presumably" because it measures electricity usage of the entire building, but not the building itself.) and meter_2 measures floor_1, etc. We can get the subsumption relations based on what they measure in queries.

In summary, I think `controls` works for your problem unless you have other reasons to associate the concepts as other feeds relations.

With regards,

Jason Koh

cseweb.ucsd.edu/~jbkoh

--
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/c2fc3c2f-13b1-4333-93d5-fd31d35c18d7%40googlegroups.com.

[Gabe Fierro]

Hi Dan:

Thanks for bringing this up --- it's an important issue to discuss, and not one for which we have a good solution yet.

I don't think controls is the appropriate relationship to use for this case: there isn't a control loop going on here, which is what the controls relationship usually implies. Instead, we should focus on the core issue: the semantics of feeds and how it relates to the flow of substances (in this case, electrons) and to the flow of information (in this case, aggregation).

We've traditionally used feeds to mean the flow of substances; Brick v1.1 introduced feedsAir to mean the flow of air between two entities. We haven't yet defined other subproperties like feedsWater or feedsLight because it's not obviously the correct modeling decision. (In writing this I digressed for about a paragraph here, but I don't think it was fruitful). Regardless of how the feedsXXX design evolves, I don't think it's the right choice here either. We should preserve feeds and its derivatives for the flow of some physical media.

Instead, I'm curious how far we could get in describing/defining entities by how they are computed from other entities. This is the general case of meter aggregation. The simple approach here would be to introduce an aggregation property to relate the meter quantities. The top-level property could be aggregation with sub-types sum, mean and so on that specify the nature of the aggregation.

Then we can model the relationship Dan mentioned in his email (I'm abusing RDF syntax here; everything in the brackets[] is in a list)

bldg:power_meter_1   brick:sum  [bldg:power_meter_2, bldg:power_meter_3]

bldg:power_meter_2   brick:sum  [bldg:power_meter_4, bldg:vav_power_meter]

bldg:vav_power_meter  brick:isPointOf   bldg:VAV_123

This of course leaves out a lot of complexity: how is the sum computed, how is data aligned, how is missing data handled, is there unit translation going on, do the power quantities make sense to add (are we trying to add single phase data with only A phase data?). I'm not sure how or whether we'd want to capture this kind of information in the properties themselves; usually these are expressed in imperative code for a reason.

I will definitely give this some deeper thought, but it seems clear to me that expressing aggregation should be handled separately from expressing the sequence of things in some physical flow.

Dan, do you have some examples of the kinds of queries you'd like to run over a model of the submetering infrastructure? This can help guide the choices we make in the model design.

Best,

Gabe

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/CAJfunc0sj%2BG50Z4dX-VO-ULy7G6FF-K0W4uVkX0aaYqhKUBy8w%40mail.gmail.com.

[Joel J. Bender]

Hi there,

I echo that this is an important topic. The design pattern for this in the Facility Smart Grid Information Model (FSGIM) has a Meter is divided into ElectricMeter and EmissionsMeter, which in turn have "measurement sets" for power, energy, and emissions. The aggregation is done by an EnergyManager that has a variety of ways of aggregating "supplied" and "consumed" measurements. These are roles, not physical devices, so the energy manager role can be performed by a physical meter, but might be performed by some other piece of software someplace on something that would be a sosa:Platform [1]. (@Steve Ray I'm probably getting that wrong.)

I do not expect that ASHRAE 223 will necessarily fully import the FSGIM model, nor do I expect Brick to, but I would like to make sure that if someone uses 223 and Brick that they don't make modeling decisions that conflict later with the FSGIM. There are design decisions in the FSGIM that separate it from the NAESB PAP10 model it was derived from, and the FSGIM doesn't talk about other utilities that are metered like chilled water, potable water, and steam. Those other utilities are metered as part of Cornell's billing and emergency demand response systems.

A bit a ramble, need more coffee.

Joel
[1] https://www.w3.org/TR/vocab-ssn/#SOSAPlatform

[Steve Ray]

Joel,

You got everything right re. FSGIM!

And yes, the FSGIM team acknowledged that there are other things to meter out there, and put stubs in the model, but restricted itself to electricity.

The other key concept that is pervasive in FSGIM is that data is collected, stored, organized, in association with an interval of time.

Still mulling over whether that is relevant to the 223 work or not.

Steve