Skip to content

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