search

BrickSchema / Brick

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

Represent electrical metering points #188

Closed danjhugo closed 3 years ago

danjhugo commented 4 years ago

The Brick schema v1.1 has some electrical metering Points, but is unable to precisely represent all cases due to insufficient specialisation of types. This makes it difficult for software to discover points in models and unambiguously know their specific meaning without any additional context. Rather than simply say "add these points", I would like to pose the problem in terms of the following questions...

  1. Electrical metering sensors are distinguished by parameters including:

    • integration (power or energy)
    • complexity (real, reactive, or apparent)
    • flow (import, export, or net)
    • phase count (single-phase,or three-phase) ...Are there any other parameters that need to be described in types?

  2. Taking the above parameters and their possible values, are there any permutations that can be excluded as illogical or vanishingly rare?

  3. In Haystack, 'net' means import minus export. Is it necessary to use the words "net import" to make this unambiguous and allow for "net export" types for metering systems that (for whatever reasons) function that way?

  4. If the answers to (2) and (3) above are respectively no and yes, then future versions of Brick would need to define at least 48 possible types of electrical meter sensor Point. Is this acceptable, or becoming excessive?

  5. Crazy alternative ideas... In the future, if it is desirable to avoid proliferation of Brick types resulting from permutations of multiple parameters (as is the case with electrical metering), is there any merit to considering how instance nodes in a model can be tagged with parameters/properties in addition to having a type (which might be generic or ambiguous), so that querying applications can better comprehend the point? For example, something like... :power_sensor_123 a brick:Power_Sensor; brick:parameter tag:Real, tag:Import, tag:Single_Phase . (Or similar.) The tradeoff here is that this appears to simplify ontology maintenance and model construction, while shifting some burden onto querying.

(Filed issue as requested by @gtfierro in forum discussion)

JoelBender commented 4 years ago

Choice (5) reminds me a lot of the Pizza ontology; you must have a base (power sensor), some toppings (import as a consumer, export as a producer) and maybe you can't have both peppers and mushrooms (Single_Phase and Three_Phase). I'm not convinced it would simplify ontology maintenance or model construction because the only difference is if the combination of restrictions has a name like Single_Phase_Import_Power_Sensor or not. I'm in the "say what you mean" camp, especially if (2) is true.

danjhugo commented 4 years ago

@JoelBender sure, I get that (although I think it's safe to disregard nonsense permutations in a pizza-ified scheme, since they shouldn't appear in the wild anyway). But I ask the question about (5) because if it turns out we need to allow for just one more binary parameter, then we (potentially) balloon to almost 100 new classes just for electrical metering, and that seems like a lot.

danjhugo commented 4 years ago
  1. If we actually require dozens of new classes, do we attempt to place them under any kind of hierarchy?
gtfierro commented 4 years ago

Thanks @danhugo for filing the issue, and I think the existential questions posed are exactly the right ones.

First, I would offer that there are maybe a couple other parameters to consider (in bold -- added from the other comment on the Google Groups thread in reference to AEMO's meter data format)

There are also related quantities voltage, current, frequency and power factor as well as related components magnitude, angle, imbalance, total harmonic distortion (these latter ones only really make sense for voltage + current). When dealing with meters + other electrical sensors, it seems important to include these in the discussion, even if there are some high-level properties that distinguish them from the power/energy discussion.

Regarding the meaning of net as to whether it is from the building's perspective (import - export) or the grid's perspective (export - import) (let me know if I misinterpreted your question in point 3) --- I think is a manner of defining our terms consistently and precisely.

Brick has long erred on the side of using single / class names (e.g. Single_Phase_Import_Power_Sensor) to simplify the usage of the ontology --- both in terms of instantiation and in querying. The resulting "type explosion" of classes typically hasn't been that large nor unmanageable. While adding 48 or 100 classes just for electrical metering may sound like a lot, I think with good descriptive tags and an intuitive class structure, we can make this workable. We don't need to add new properties that often, so its more of a slow expansion than an explosion.

The point you raise about adding properties to the instances rather than pushing that metadata into the class is a good one (I believe this is called "putting typing into the A-box" or something along those lines). Given Brick's class-centric design, I'm reluctant to wholly adopt the design, but I think there is a useful middle ground. Some properties are more fundamental to what something "is" than others. In the context of the Pizza ontology, each unique combination of toppings does not merit a new "type" of pizza, but the choice of red sauce or white sauce is perhaps fundamental to the kind of pizza at hand.

Properties/parameters that I would consider fundamental here include integration, complexity, flow and phase. However, the units would be a property of the instance. As would whether or not the quantity is estimated or measured.

It is worth pointing out that we've done a little bit of both of these approaches in Brick under the Sensor hierarchy. Certain classes are described in terms of their properties, which gives multiple ways of describing and querying for that concept:

:abc    a   brick:Discharge_Air_Temperature_Sensor .

# equivalent (using OWL reasoning)

:abc    a   brick:Sensor ;
    brick:measures brick:Discharge_Air, brick:Temperature .

This pushes complexity into the ontology but at the benefit of allowing flexibility + simplicity in the querying + instantiation. Classes are nice for instantiation + querying because one can just use the term for what it represents rather than relying on additional properties to make the term sensical. Properties (e.g. measures Temperature) are helpful for exploratory queries about what is in a model and what properties of the building are included in the model.

I'm leaning towards just creating the 48/100/etc classes we would need to capture all of the desired properties, and making those properties explicit the definition of the class much like we do for Sensors.

david-waterworth commented 4 years ago

I posted this on the original discussion - it's the schema AEMO use to represent physical meters. The CATS_METER_REGISTER is the core entity. There's a whole bunch of fields which may be necessary in some cases - i.e. many older style induction meters have a multiplier which needs to be applied to the reading.

The meter we're discussing here is a virtual meter - an AEMO NMI (national metering identifier) which is an aggregation of one or more physical meters. The data streams are curated, it's not possible to access the meters directly, you receive the data from the meter data provider. So not sure if a distinction should be made between a physical and virtual meter and does this concept exist outside of the AU NEM.

This then introduces the `quality flag' concept which I mentioned:

image

Not only can you get multiple versions of a historical point, you can also receive a `forecast' (i.e. E or estimated) - as opposed to S (subsituted) for missing data.

When I've modelled this I've had a NMI which has multiple data streams. Each data stream has multiple samples (a timeseries) and eachsample has a timestamp, value and quality flag. Not sure how this would translate to a metadata schema.

I also see parallels between a NMI and a physical site meter, and an onsite weather station vs getting the local weather from an external provider. Both represent the same underlying `thing' (consumption vs weather) and both are obtained via a different mechanism (reading a sensor vs obtaining a dataset from a service)

gtfierro commented 4 years ago

Thanks @david-waterworth for reposting this here!

I like the idea of being able to identify the "quality" of the data. This might be a good candidate for a property of an instance --- perhaps even for instances that are Point classes but aren't meters --- but I'm not sure I have a good reason why it would be a property of an instance rather than a new class :). I like the idea of using properties for describing aspects of how the data is computed/delivered, whereas a class would be used to describe physical/functional properties of the deployment/system/context.

I also found a list of units in the file format documents you shared and I think these are some good candidates for suggesting to QUDT (so they can also show up in Brick).

I didn't find anything about enumerations of integration or complexity parameters --- did I miss anything in the document, or are those sufficiently characterized by the units?

david-waterworth commented 4 years ago

Hi Gabe

I'm not sure the term integration is in the document, but what's referred two as a 'basic' meter is an accumulator style meter. In order to obtain the consumption between two reads you have to subtract the readings - so this is sometimes called integrated because you have to difference the series. Also often you have to apply a multiplier as 1 unit may represent say 0.0001 kwh. Chiller energy consumption is sometimes an accumulator style. It's more robust if there's a chance of missing a reading when dealing with energy (kWh) time series.

The term complex power comes from the way engineers represent AC power as complex numbers (https://electrical-engineering-portal.com/complex-power-analysis) - the units you've identified so I don't think you've missed anything. Real (P in kW) and Reactive (Q in kVar) power can be represented as a complex number P+jQ. The apparent or actual power (S in kVA) is the magnitude sqrt(p^2+Q^2) and the power factor is the cosine of the angle theta.

JayDub69 commented 4 years ago

Hi @gtfierro - Interesting topic and great to hear this is being looked at!

Suggested parameters in the context of energy and power that @danhugo and I have come across while attempting to model data from over 600 electrical meters (billing meters and sub-meters) across our organization in Australia include:

In regards to Flow, from the meters we have looked at, in addition to import (i.e. into load) and export, there is also: net (or signed) = import - export absolute = import + export

In regards to Phase, perhaps its not which phase it is that is important but whether it is a single phase sensor or a total aggregation of all phases (e.g. Total_Phase_Active_Power_Sensor) noting that it could be a 1, 2, 3 phase or greater multi-phase circuit!

Max Demand (in a power context) is an interesting one often used in billing, as it is typically the maximum Apparent Power measured over a particular interval. This could be a standard 5, 15 or 30 min AMI interval, or a monthly or even yearly interval often used to calculate network/demand/capacity charges.

We are continuing to discover more sensor parameters the deeper we dig...!

david-waterworth commented 3 years ago

One thing I would add in the Australian context is a NMI isn't a meter, it's the ID of a connection point. I see them as separate concepts and it's of benefit to model them explicitly. A connection point in the AUS market represents where energy changes ownership (generation to transmission, transmission to distribution, distribution to site etc). There is/are physical meter(s) associated with the connection point which have meter data streams (kW, kVAr etc.) and a serial number per meter. The connection point itself has metadata such as the network, the meter data provider (MDP), the ORG who reads the meters, processes the data and provides the data to market participants (forecasts, readings, estimates) etc. This is where additional complexities such as peak demand (a computed quantity), quality flags etc are added - they're not really properties of the meter. Both the physical meters and the connection point attributes can change over time, splitting them makes this easier to manage. Also the meters are locked up - only the MDP has access. So we get our NMI data from the MDP or an electricity bill, not the meters.

gtfierro commented 3 years ago

Hi all:

Apologies for being away from this discussion, but I put together a little prototype that should serve as a nice strawman for moving the discussion forward. I'm borrowing some of the ideas we are discussing on the https://github.com/BrickSchema/Brick/issues/189 issue about instance metadata

    # implicit in class name
    # - Complexity (Real Power)
    # - num phases (1)
    :abc1    a  brick:Single_Phase_Real_Power_Sensor ;
        brick:powerFlow         "net" ; # net defined as import - export
        brick:powerPhase        "A" ;
        brick:aggregate [
            meta:aggregation    "mean" ;
            meta:aggregationInterval    "15min" ; # need some standard representation
        ] .

How to express peak yearly demand:

    :abc2   a   brick:Total_Phase_Real_Power_Sensor ;
        brick:powerFlow         "net" ;
        brick:numPhases         "3"^^xsd:integer ;
        brick:aggregate [
            meta:aggregation    "max" ;
            meta:aggregationInterval    "year" ; # need some standard representation
        ] .

How to tie this into a meter entity:

    :meter1 a   brick:Building_Meter ;
        brick:hasPoint  :abc1, :abc2 ;
        brick:hasIdentifier [
            a   csiro:NMI ;
            qudt:value  "12345678901" ;
        ] .

This implementation depends on the following enumerations:

@david-waterworth I see your comment about the additional metadata associated with the reporting, governance, provenance and networking properties of the meter. I think that the kinds of properties we are discussing on https://github.com/BrickSchema/Brick/issues/189 can help here, though we will probably need to introduce some new concepts e.g. ConnectionPoint that describe some of the networking and regulatory components necessary. Are you aware of any existing standards or documents we could use to seed that discussion?

david-waterworth commented 3 years ago

@gtfierro this may help although it's not overly accessible.

Section 2 for example describes the 5 tables the market operator uses. In particular, there will be one entry in CATS_NMI_DATA for each NMI, and 1 or more in CATS_METER_REGISTER for each meter associated with the NMI (large sites usually consist of many NMI's as well - I think generally each main and mechanical switchboard often (always?) has it's own NMI).

gtfierro commented 3 years ago

Hi all! I'm working on a prototype of how to address these kinds of properties (I'm calling them EntityProperties for now), and I posted about it on a different issue https://github.com/BrickSchema/Brick/issues/189 . I took a stab at incorporating many of the electrical metering point properties discussed above. Please take a look and let me know what you think! There's an example at the bottom of the implementation file

gtfierro commented 3 years ago

Got a new version of the prototype, which is available at https://github.com/BrickSchema/Brick/pull/203 . If anyone has time to check it out and give it a try with some of your points, any feedback you have would be very valuable. All comments welcome!

Here are some examples under this proposal:

#  single-phase active power sensor that measures net power
:meter1 a   brick:Power_Sensor ;
    brick:hasUnit   unit:KiloW ;
    prop:hasComplexity   [
        prop:value  "active" ;
    ] ;
    prop:hasPowerFlow   [
        prop:value  "net" ;
    ] ;
    prop:hasPhaseCount   [
        prop:value  "1"^^xsd:integer ;
    ] ;
    prop:hasIP6Address  [
        prop:value  "fe80::1",
    ] .

:daily_energy_usage_meter   a   brick:Energy_Sensor ;
    brick:hasUnit   unit:KiloW-HR ;
    prop:aggregate [
        prop:aggregationFunction    "sum" ;
        prop:aggregationInterval    "1d" ;
    ] ;
    prop:hasComplexity [
        prop:value  "active" ;
    ] ;
    prop:hasPowerFlow [
        prop:value  "net" ;
    ] 
.

:hourly_peak_real_power_meter   a   brick:Power_Sensor ;
    brick:hasUnit   unit:KiloW-HR ;
    prop:aggregate [
        prop:aggregationFunction    "max" ;
        prop:aggregationInterval    "1h" ;
    ] ;
    prop:hasComplexity [
        prop:value  "real" ;
    ] 
.
JayDub69 commented 3 years ago

@gtfierro - I like this EntityProperties proposal!

Some questions we have are:

  1. PowerComplexity (active, reactive, apparent) - Given these are fundamental sensors for both electrical energy and power, are these best represented as Brick classes instead of entity properties e.g. Active_Energy_Sensor, Reactive_Energy_Sensor, Apparent_Energy_Sensor Active_Power_Sensor, Reactive_Power_Sensor, Apparent_Power_Sensor

  2. PhaseCount (1, 2, 3) - Can this property sufficiently imply a 'total' phase sensor e.g. Total_Active_Power_Sensor i.e. the sum of all phases (note: meters could have a total phase count of 1,2 or 3)?

  3. EntityType (logical, physical, virtual) - What is the best way to represent a virtual entity (a virtual meter or virtual meter sensor in this context)? Is a class, Tag or entity property best used for this?

  4. In regards to modelling a virtual meter and the relationships between the physical components and the parent virtual meter, is the isPartOf relationship best used for this? (see diagram below)

image

corymosiman12 commented 3 years ago

I was just looking at this thread as I had Electrical_Energy_Sensor on my to Add list (here: https://github.com/BrickSchema/Brick/issues/197#issuecomment-767821273). I noticed in the v1.2 branch there is no subclass of Energy_Sensor that is Electrical_Energy_Sensor, which would then I believe have Active_Energy_Sensor and the others as subclasses https://github.com/BrickSchema/Brick/blob/708ff7e33f89106513dba6fba9b8fa16c827865e/bricksrc/sensor.py#L267

That make sense?

gtfierro commented 3 years ago

Hey @JayDub69 thanks for looking through the proposal, and sorry for the delay in my reply!

PowerComplexity (active, reactive, apparent) - Given these are fundamental sensors for both electrical energy and power, are these best represented as Brick classes instead of entity properties e.g. Active_Energy_Sensor, Reactive_Energy_Sensor, Apparent_Energy_Sensor Active_Power_Sensor, Reactive_Power_Sensor, Apparent_Power_Sensor

I'm torn how to address this, but there are basically two options:

  1. eliminate the Brick classes that are replaced by Entity Properties (e.g. remove Apparent_Energy_Sensor and replace it with an Energy_Sensor with a prop:hasPowerComplexity with a prop:value of "apparent").
  2. Establish the two representations as equivalent, so you can use either representation and have Brick figure out the other one automatically and add it to your graph. This can be done with SHACL-AF features.

I'm still working through the pros/cons of the two approaches. I'd like to be able to support the second one, but I'm not sure if it is worth the complexity.

PhaseCount (1, 2, 3) - Can this property sufficiently imply a 'total' phase sensor e.g. Total_Active_Power_Sensor i.e. the sum of all phases (note: meters could have a total phase count of 1,2 or 3)?

Absolutely! A "wart" of the implementation is that this now means that the PhaseCount property has to be a string rather than an int so that the types are consistent. I've got this code implemented in the #203 branch

EntityType (logical, physical, virtual) - What is the best way to represent a virtual entity (a virtual meter or virtual meter sensor in this context)? Is a class, Tag or entity property best used for this?

Currently, entities can be virtual but we haven't had a specific way of pointing this out. Tags are essentially devoid of meaning, so I think the right way is either as an EntityProperty (feels like overkill), or maybe a separate Brick class (brick:VirtualEntity) that an instance can also instantiate? So you'd have:

:mymeter a brick:Electrical_Meter, brick:VirtualEntity .

That way, if you care if an entity is virtual, you can ask the graph, but you can also treat the meter agnostic to this implementation detail.

In regards to modelling a virtual meter and the relationships between the physical components and the parent virtual meter, is the isPartOf relationship best used for this? (see diagram below)

What is the nature of the relationship you are trying to capture? Do the individual meters "sum up" to the virtual meter? I think we have been using brick:feeds to denote the flow of information here, but I don't think we've specifically advised either way.

gtfierro commented 3 years ago

Closing this issue due to the merge of #214 and the release of v1.2. There are still some outstanding issues with Electrical metering points, and plenty more to model, but I recommend that the conversation be focused in dedicated issues such as #236 that reflect the changes in v1.2. Thanks to everyone who helped inform the entity properties feature! Looking forward to further improving it with guidance from the community