Electrical Modelling Norms

Energy metering Polarity Requirements

Devices and meters are wired differently depending on where and how they are installed and what their purpose is. In DCH, for Semantic modelling and queries to provide unambiguous results, the following rules must be followed.

Preferred Approach

The following configurations are the preferred approach to providing timeseries data and classification of Points relating to metering.

Classification	Data Polarity	Description/Usage
net	Positive or Negative values	Positive values represent energy/power flowing from the grid towards meters or devices in the model (Consumption) Negative values represent energy/power flowing from meters or devices in the model towards the grid (Generation)
import	Positive values only	Positive values represent energy/power flowing from the grid towards meters or devices in the model (Consumption)
export	Positive values only	Positive values represent energy/power flowing from meters or devices in the model towards the grid (Generation)

Use of Scale Factor

When it is not practical to change the polarity of the data arriving into DCH for a Net, Import or Export Point to meet the above requirements, you MUST add a scaleFactor entity property to the Point to ensure that data queries provide unambiguous results.

DCH allows Points to be assigned a scale factor via an Entity Property. Scale factors contain a scale and an offset. These alternate solutions use -1 for the scale component to let the system know that the polarity of the stored timeseries data should be inverted for correct interpretation.

This solution does not instruct the system to correct the polarity of the data as it is ingested (i.e. it is still ingested and stored as it is supplied), rather the solution provides a flag that informs that the polarity of the data should be inverted when it is read out to be used.

Classification	Data Polarity	Description/Usage
net scaleFactor (scale) = -1	Positive or Negative values	Negative when energy/power flows from the grid towards meters or devices in the model (Consumption) Positive when energy/power flows from meters or devices in the model towards the grid (Generation)
import scaleFactor (scale) = -1	Negative values only	Negative values represent energy/power flowing from the grid towards meters or devices in the model (Consumption)
export scaleFactor (scale) = -1	Negative values only	Negative values represent energy/power flowing from meters or devices in the model towards the grid (Generation)

General

1. Any brick:Electrical_Meter SHOULD have brick:meters relationship with one or more equipment/system. This does NOT apply for brick:Building_Electrical_Meter and brick:Site_Electrical_Meter as these classes can be isolated nodes.

2. An Electrical_Meter that is close to the site point of connection to the grid and which meters all other buildings/equipment on a site MUST have the type brick:Site_Electrical_Meter.

3. An Electrical_Meter that is not a brick:Site_Electrical_Meter, and which feeds a whole building (and feeds no other buildings), MUST have the type brick:Building_Electrical_Meter.

4. An Electrical_Meter that meters only a generation installation MUST have type brick:Electrical_Generation_Meter.

5. An Electrical_Meter that meters only a storage installation MUST have type brick:Electrical_Storage_Meter.

6. An Electrical_Meter that does not fit a more specific type MUST have the type brick:Electrical_Meter.

7. An Electrical_Meter of any type MUST NOT feed a location.

8. A meter MAY be partOf some larger equipment.

9. A generation installation MUST be represented by the most suitable class of Inverter:

   1. for a conventional solar inverter, use a brick:Solar_Inverter

   2. for an inverter with both solar and battery capabilities, use a brick:Hybrid_Inverter

   3. for any other type of generation, use a brick:Inverter

10. A solar generation installation SHOULD have solar panels modelled either individually or as an array (see PV Modelling for more detailed breakdown).

11. A generation installation composed of multiple inverters MAY be modelled as a single inverter entity if their number is unknown; otherwise they MUST be modelled as separate entities.

12. An array of electrically connected solar panels MUST be represented by at least one brick:PV_Array instance; it MAY be represented by multiple discrete panels if their details are known.

13. A battery storage system MUST be represented by the most suitable class:

    1. for an inverter with both solar and battery capabilities, a brick:Hybrid_Inverter MUST be used.

    2. for a battery plus inverter combination where details are known, a brick:Battery_Inverter_Charger and separate brick:Battery SHOULD be used.

14. Any Electrical_Equipment which has self-metering capability SHOULD have those points modelled to the equipment and not a separate meter (even if the stream IDs are unknown).

15. Electrical equipment (including meters, storage and generation types) MUST have their location set to the most specific true location (site, building, floor, room) if known.

16. The location of electrical equipment (including meters, storage and generation types) does not imply electrical connection to that location's other electrical assets.

17. Any Power usage or GPIO Equipment/System MUST be represented by the generic classes in BRICK (I.e. Electrical_Equipment/Electrical_System) and the entity property of brick:type MUST be added to the equipment to indicate that the equipment is Power, GPIO etc.

18. Lighting equipment/system MUST be represented as brick:Lighting_Equipment/brick:Lighting_System.

19. brick:electricalPhaseCount, brick:electricalPhases, brick:powerFlow and brick:powerComplexity MUST be set for electrical equipment/points. Refer to the table below for entity property norms.

Device type	brick:electricalPhaseCount	brick:electricalPhases	brick:powerFlow	brick:powerComplexity
Single phase device	1	A/B/C	net/import/export	real/reactive/apparent
Three phase device	3	ABC	net/import/export	real/reactive/apparent
One phase in a three phase device	1	A/B/C	net/import/export	real/reactive/apparent

Self-metering Equipment

Many equipment have self-metering capability which can confuse the model and anybody who is using the model. These devices can be inverters, batteries, EV chargers, hot water heat pumps, AHUs, etc.

1. You MUST create virtual meter with class brick:Electrical_Meter that has the brick:meters relationship with the equipment and have the brick:isVirtualMeter Entity Property.

2. If an upstream meter exists the virtual meter MUST be related to it by a hasSubMeter relationship.

3. You MAY have the virtual meter be part of the equipment with the isPartOf relationship.