Ontology Working Group Notes

2021-04-15

Chiller Plants and Heat Pumps

Agenda:
- heat pump implementation discussion
- systems / loops
reversing valve commands:
- does 1 mean 'heating' and 0 mean 'cooling'? or some other configuration
- some role for an 'entity property' that says normally 'heat' vs normally 'cool'; normally 'left' vs 'right'?
- need some sort of enumeration that defines what the values of the reversing valve mean
- another approach: an Reversible X to Y heat pump will source heat from X to heat Y. If the valve is reversed, then heat flows in the other direction
- need to be able to express what the "reversed" direction means
for the class structure:
- maybe over-specialized?
- have a Reversible Heat Pump and NonReversible Heat Pump class
- these could be parents of the X to Y heat pumps; an entity is a member of two classes
- Alternative: reversible vs non-reversible could be entity properties
complications:
- water to water heat pump:
  - pulling energy otu of space, running chiller at a higher pressure
  - can use the hot water coming out of the chiller as a hot water source
- "four pipe systems":
  - air to air systems but it can suck and distribute heat in different directions
  - can reject heat into any of the loops at one point in time
  - if you have heating and cooling demands in the building at the same time, this can be much more efficient
- this needs the ability to express loops
- condenser water loop:
  - can contain either hot water or cold water depending on the seasonality
  - could be pulling heat out or putting heat in
  - harder to express the idea of a "hot water" loop or a "chilled water" loop because what is in the loop will change over time depending on the configuration + season
people think of an equipment as "pushing" heat or "pushing" cool into the loop:
- or it is reversible; reversible is part of that enumeration
- if the heat flow is reversible, then you need to query some other point to tell you what state it is in
- could represent this as a "heating/cooling" mode:
  - either a static property or a Point
can refer to two sides as "outdoor coil" and "indoor coil":
- function of the two coils changes when the valve switches
- however these terms don't generalize to water to water and water to air
questions:
- who is feeding that coil?
- which equipment should I dispatch to get the hot or cold water to that coil in the most efficient or cost-effective manner?
Articles for background:
- https://www.nxtbook.com/nxtbooks/ashrae/ashraejournal_JPPKRR/index.php#/p/24
- https://louisville.edu/housing/info/policies/procedures/hvac

2021-04-06

Chiller Plants and Heat Pumps

Goal: to arrive at a coherent and flexible class-based representation of heat pumps and chiller plants in Brick.

The way that I propose to approach this is to make a list of the broad types of equipment that will need to be modeled. For each of these, we will make a list of the properties and enumerations that must be captured. Some of these will be folded into the class organization; others will be implemented as entity properties.

Competency Questions:

"what thermal machine is providing the heating/cooling in this building?"
"where does room/VAV/zone X get its hot air from?" "what heats that hot air?"

Outline of the solution:

Class structure:
- Establish a Heat Pump class, which subclasses from HVAC Equipment.
- Define subclasses of Water-Sourced, Air-Sourced and Ground-Sourced heat pumps:
  - organizes heat pumps by the non-load-side resource
- Define subclasses of the above which indicate the load-side resource, e.g. Water-To-Air Heat Pump:
  - some of these are further subclassed as reversible or non-reversible
- Class structure contains Chillers as a subclass of Heat Pump:
  - some Chiller subtypes are also listed under the X-to-Y Heat Pump classes
- see all classes at https://github.com/BrickSchema/Brick/pull/252
Semantic properties of classes:
- When you build a model, it is easiest to indicate the asset type:
  - e.g. "X is a water-cooled chiller"
- When you query a model, want the option of identifying equipment by its function
  - e.g. "what resource is cooling the water going to the cooling coil?"
  - or you can query by type: "which kinds of chillers does the site have?"
- Use SHACL or OWL inference to provide this property
Key to this implementation will be the ability to describe a particular heat pump using either the class name (for well-known configurations) or a set of properties.
Then the system will be able to figure out when those two different methods of expression are equivalent

How to parameterize heat pumps?:

heat flow direction:
- heat or cool
- this may be a static property, e.g. for non-reversible heat pumps
- or it maybe a dynamic property for reversible heat pumps
reversible vs non-reversible:
- a static property that tells whether or not the heat pump is reversible
load-side resource:
- what is heated or cooled: Air, Water, Refrigerant
non-load-side resource:
- what is the medium acting as the reservoir of heat or the sink?
- we could not think of a good industry-standard term that is generic to whether the heat pump is heating or cooling
- if cooling, the non-load is a "sink"
- if heating, the non-load is a "source"
- if in a reversible system, the non-load may be a source or a sink!
- in certain kinds of systems, the two sides are called evaporator-side and condenser-side
- Given that many technical documents refer to "Air-Source" or "Ground-Source" heat pump, even in cooling configurations, it makes sense for the non-load resource to be referred to as a "source"
heat pump composition and topology:
- most heat pumps are single package units
- as a result, we expect most heat pumps models to simply instantiate the correct heat pump class and attach Point instances using brick:hasPoint
- in more advanced use cases, one may instantiate some components of the heat pump and attach them to the heat pump using brick:hasPart:
  - e.g. for modeling reversing valves
- in even more advanced use cases, one may model the connections between the components of the heat pump using brick:feeds. However, this raises an issue as we will see below

Example models:

each of these builds on the previous ones

instantiating a reversible air-to-air heat pump

@prefix brick: <https://brickschema.org/schema/Brick#> .
@prefix bldg: <urn:bldg#> .

bldg:heatPump1  a   brick:Reversible_Air_To_Air_Heat_Pump ;
    brick:hasPoint  bldg:dis_air_sensor .
bldg:dis_air_sensor a   brick:Discharge_Air_Temperature_Sensor .

modeling the reversing valve w/ direction

@prefix brick: <https://brickschema.org/schema/Brick#> .
@prefix bldg: <urn:bldg#> .

bldg:heatPump1  a   brick:Reversible_Air_To_Air_Heat_Pump ;
    brick:hasPoint  bldg:dis_air_sensor ;
    brick:hasPart   bldg:rv .
bldg:dis_air_sensor a   brick:Discharge_Air_Temperature_Sensor .
bldg:rv a   brick:Reversing_Valve ;
    brick:hasPoint  bldg:rv_cmd .
bldg:rv_cmd     a   brick:Reversing_Valve_Command .  # determines heat/cool mode

modeling more internal composition of the heat pump

@prefix brick: <https://brickschema.org/schema/Brick#> .
@prefix bldg: <urn:bldg#> .

bldg:heatPump1  a   brick:Reversible_Air_To_Air_Heat_Pump ;
    brick:hasPoint  bldg:dis_air_sensor ;
    brick:hasPart   bldg:rv, bldg:evaporator1, bldg:condenser1, bldg:compressor1 .
    
bldg:dis_air_sensor a   brick:Discharge_Air_Temperature_Sensor .

bldg:rv a   brick:Reversing_Valve ;
    brick:hasPoint  bldg:rv_cmd .
bldg:rv_cmd     a   brick:Reversing_Valve_Command .  # determines heat/cool mode

bldg:evaporator1    a   brick:Evaporator .
bldg:condenser1     a   brick:Condenser .
bldg:compressor1    a   brick:Compressor ;
    brick:hasPoint  bldg:comp_start ;
.
bldg:comp_start a brick:Start_Stop_Command .

adding internal topology of the heat pump

@prefix brick: <https://brickschema.org/schema/Brick#> .
@prefix bldg: <urn:bldg#> .

bldg:heatPump1  a   brick:Reversible_Air_To_Air_Heat_Pump ;
    brick:hasPoint  bldg:dis_air_sensor ;
    brick:hasPart   bldg:rv, bldg:evaporator1, bldg:condenser1, bldg:compressor1 .
    
bldg:dis_air_sensor a   brick:Discharge_Air_Temperature_Sensor .

bldg:rv a   brick:Reversing_Valve ;
    brick:hasPoint  bldg:rv_cmd .
bldg:rv_cmd     a   brick:Reversing_Valve_Command .  # determines heat/cool mode

bldg:evaporator1    a   brick:Evaporator .
bldg:condenser1     a   brick:Condenser .
bldg:compressor1    a   brick:Compressor ;
    brick:hasPoint  bldg:comp_start ;
.
bldg:comp_start a brick:Start_Stop_Command .

# this is where we run into modeling issues. There are two "correct" ways
# to model the topology, depending on which mode the heat pump is in: heat/cool
# if in heating configuration...
bldg:evaporator1    brick:feeds bldg:compressor1 .
bldg:compressor1    brick:feeds bldg:condenser1 .
bldg:condenser1     brick:feeds bldg:evalve1 .
bldg:evalve1        brick:feeds bldg:rvalve1 .
bldg:rvalve1        brick:feeds bldg:evaporator1 .

# if in cooling configuration...
bldg:evaporator1    brick:isFedBy bldg:compressor1 .
bldg:compressor1    brick:isFedBy bldg:condenser1 .
bldg:condenser1     brick:isFedBy bldg:evalve1 .
bldg:evalve1        brick:isFedBy bldg:rvalve1 .
bldg:rvalve1        brick:isFedBy bldg:evaporator1 .

# one solution is to introduce a *new* relationship which
# captures topology but not direction
brick:connectedTo   a   owl:ObjectProperty .
brick:feeds rdfs:subPropertyOf  brick:connectedTo .
brick:isFedBy rdfs:subPropertyOf  brick:connectedTo .

# rather than feeds/isFedBy, the model can just capture
# the connections instead of direction. This is now correct
# in either configuration
bldg:evaporator1    brick:connectedTo bldg:compressor1 .
bldg:compressor1    brick:connectedTo bldg:condenser1 .
bldg:condenser1     brick:connectedTo bldg:evalve1 .
bldg:evalve1        brick:connectedTo bldg:rvalve1 .
bldg:rvalve1        brick:connectedTo bldg:evaporator1 .

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ontology Working Group Notes

2021-04-15

Chiller Plants and Heat Pumps

2021-04-06

Chiller Plants and Heat Pumps

Clone this wiki locally