Relationship Diagrams

Metering Hierarchy

Current state

The Brick ontology does not set out a clear way on modelling sub-meter relationships and meter load relationships. Currently, people tend to default to representing these relationships with the standard relationship given by Brick: feeds.

While this approach provides a simple way to connect entities, it does not feel like the appropriate solution for the following reasons:

1. brick:feeds is generally targeted at capturing the flow of some physical media [1]
2. Following from above, meters generally do not 'feed' physical media to another entity (e.g.: meter to AHU). Rather, meters measure the flow of physical media (gas, water, electrons) between entities.
3. Meters do not feed each other, either. Meters are independently placed on the network. Their placement dictates where they sit in the submetering hierarchy with the other meters; they are not physically (directly) connected to each other.
4. Meters should not be considered in-line with physical media pathways; i.e. a meter could be added or removed to the network and should not change the existing relationships between (non-meter) entities. e.g.: Adding a Thermal meter on an AHU should not change the brick:feeds relationship coming from the HHW/CHW plant/supply loop to the AHU. Rather the meter is simply measuring that flow/energy transfer and should be referenced as the addition it is.
5. Electrical meters can record both an 'import' and an 'export' energy value. By having meters 'feed' each other (uni-directional) the nature of the bi-directional energy flow is obscured.

Proposed State

From a relationships persective, the important information that needs to be captured is:

1. Submetering relationships: where does a meter sit relative to its peers (upstream, downstream).
2. Load relationships: what non-meter entities are directly downstream being measured (generation, consumption sources).
3. Meter location: where a meter is located. Either as:
   • brick:isPartOf a distribution board or some other container
   • brick:hasLocation of a defined location in the model, if it is a stand-alone meter.

The meter location component is well covered by Brick already and will not be considered below.

The following two additional relationships are proposed. It is noted that these do not quick fit into the existing relationship strategy well; the relationships are too specific to a particular scope and include equipment types in their definitions, however it is hoped that the intent of these relationships can be expanded on and added to Brick.

• brick:hasSubmeter / brick:isSubmeterOf
• brick:hasLoad / brick:isLoadOf

An example of the meters shown above using the updated relationship is provided below:

Main HVAC Equipment Relationships

The following diagram lays out at a high level the general set-up, intermediate entities, and standard relationships used when creating a typical building HVAC model. The core principles are as follows:

1. Every line connection is a brick:feeds relationship unless otherwise indicated.
2. Entities contained within another part all have additional brick:isPartOf relationships to the container.
   e.g.: Chiller brick:isPartOf Chilled Water System
3. All brick:System entities have both a leavingHeader and enteringHeader brick:WaterDistribution entity. These entities are a convention that provide a common entry and exit point from a system.
4. brick:System entities generally have a supplyLoop and returnLoop brick:WaterDistribution entity. These entities are not part of the system. These entities serve to connect all downstream entities to the system and provide a convenient way to capture physical media flows around the building. Systems may have single loops (as shown), multiple primary loops, primary-secondary-tertiary loops, or some other combination. The loops always connect to the System entering and leaving headers.