BrickSchema / Brick

Uniform metadata schema for buildings
http://brickschema.org/
BSD 3-Clause "New" or "Revised" License
287 stars 77 forks source link

Reintroducing the Concepts of Supply/Return Temperature Sensors and Setpoint for the Water Systems #628

Open saiprasadbalaji opened 4 months ago

saiprasadbalaji commented 4 months ago

For the water systems, I propose reintroducing the terms “supply” and “return” which were deprecated recently in favour of the terms “leaving” and “entering”. In the context of BMS, the distinction between "supply/return" and "entering/leaving" is crucial, especially when dealing with a common header. Therefore, I propose bringing back the terms "supply" and "return" due to the following reasons: image

  1. Supply and Return Temperature Sensors are associated with the load side of the chilled water system.
  2. Entering and Leaving Temperature Sensors are associated with the evaporator side of the chilled water system.

For Hot water system, image

  1. Supply and Return Temperature Sensors are associated with the load side of the hot water system.
  2. Entering and Leaving Temperature Sensors are associated with the boiler side of the hot water system.

Thanks, Sai

gtfierro commented 4 months ago

Hi there @saiprasadbalaji! Good to meet you and thanks for raising this issue.

We talked a little bit about this issues with @connorjcantrell today. My understanding from the description you gave is that the re-introduction of Supply/Return would allow you to more easily differentiate between points relating to the system vs points relating to individual equipment w/n the system; in the absence of other contextual information (i.e., having those entities modeled in the graph), the tendency would be to imbue the point classes with additional semantic meaning that differentiates between those cases.

I would like us to think more about how we could solve this w/o having to have points that insist on what kind of entity they are connected to. Could we have mock "stub" systems that are eventually resolved into a single "known" entity? Or some global "virtual" system that can own points before we know what instance they are associated with. Essentially, I think we can address this issue by figuring out a way that points can be associated with a TYPE of entity without having to know what INSTANCE of that entity happens to have that point. Do I understand this ok? @connorjcantrell please chip in with your thoughts too!