Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add reheat and ability to represent dehumidification process #561

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

connorjcantrell
Copy link
Contributor

@connorjcantrell connorjcantrell commented Sep 6, 2023

Proposing to add commands, sensor, and equipment classes to support the dehumidification process in the Brick ontology. Specifically, we are introducing the following:

  • Reheat Command
  • Coiling Coil Supply Air Temperature (SAT) Sensor
  • Dehumidification Command

Why These Additions are Necessary

Reheat Command

The reheat command is needed for distinguishing the heating command needed to reheat the supply air post-dehumidification. Without a dedicated reheat command, it isn't possible to decouple the reheat operation from other heating operations within an HVAC system.

Coiling Coil SAT Sensor

The Cooling Coil SAT Sensor is used for monitoring the temperature of the supply air immediately after the cooling coil. This is used to modulate the amount of cooling used dehumidify the air before it is reheated to the target supply air temperature setpoint.

Dehumidification Command

Dehumidification Command is used to initiate the control sequence using the introduced concepts listed above.

@connorjcantrell
Copy link
Contributor Author

I accidentally added Reheat SAT sensor. I corrected it with "Cooling Coil Supply Air Temperature Sensor"

@gtfierro
Copy link
Member

This looks good for the most part, but I want to talk a little more about the Cooling Coil SAT Sensor. In Brick we are trying to get away from having the names of the equipment inside the point names. If the SAT sensor is immediately after the coil, then we should find a way of representing that explicitly within the model, e.g. by relating it to an instance of the cooling coil.

Doing this properly means we'll have to put a Sensor Equipment right after the Cooling Coil. Maybe the way we capture this concept is with a shape?

bsh:Cooling_Coil_Supply_Air_Temperature_Sensor a sh:NodeShape, owl:Class ;
  sh:class brick:Supply_Air_Temperature_Sensor ;
  sh:property [
    sh:qualifiedMinCount 1 ; sh:qualifiedMaxCount 1 ;
    sh:path brick:isPointOf ;
    sh:qualifiedValueShape [ sh:node bsh:CoolingCoilDownstreamSensor ]
] 
  sh:rule [
    a sh:TripleRule ;
    sh:subject sh:this ;
    sh:predicate rdf:type ;
    sh:object brick:Supply_Air_Temperature_Sensor ;
 ]
.

bsh:CoolingCoilDownstreamSensor a sh:NodeShape, owl:Class ;
  sh:class brick:Sensor_Equipment ;
  sh:property [
    sh:qualifiedMinCount 1 ; sh:qualifiedMaxCount 1 ;
    sh:path brick:isFedBy ;
    sh:qualifiedValueShape [ sh:class brick:Cooling_Coil ]
] ;
.

In your model, you could instantiate it as follows:

:ahu a brick:AHU ;
  brick:hasPart :cc, :se .

:cc a brick:Cooling_Coil ;
  brick:feeds :se .

:se a brick:Sensor_Equipment ;
  brick:hasPoint :sat .

:sat a bsh:Cooling_Coil_Supply_Air_Temperature_Sensor.

What do you think? The CCSAT Sensor has a rule which adds the correct Brick point class to the instance

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants