Labeling BMS data from office buildings
Dmitry Surugin
Dear BRICK Community,
First of all, thank you for a great open-source initiative which benefits the smart building industry.
Our company is working on development of a platform for data analytics and predictive energy optimization of buildings. We are connecting to existing BMS, running grey-box models in a cloud, and actively control HVAC systems. To enhance replicability, we decided to go BRICK for creating building typologies and mapping BACnet points. For the cases when some registers are not represented in the recent ontology, we are planning to create custom sub-classes on top of existing structures.
To begin with, as a new BRICK user I have a few questions/proposals related to the classification of certain data-points, and would be grateful if someone could address it here. Please let me know, what would it be the preferable communication approach - shall I post similar questions here, or use GitHub issues instead?
# related to AHU & hot water distribution system
1. Calculated dT (BACnet type 'AV', shows difference between the setpoint and actual value of process variable, e.g. discharge air temperature sensor/setpoint). Which BRICK point should I use for this?
2. delta-T threshold for activating & deactivating control loop. (BACnet type 'AV', 'degreesCelsius', specifies threshold to generate/abolish heating/cooling requests sent to downstream control elements, e.g. if supply temp. setpoint minus supply temp. measurement is higher than "threshold" → activate a certain control loop: heating coil/or heat wheel). Would "differential temperature setpoint" be applicable here, or it implies only for difference between two measurements (e.g. discharge/return air temperature sensor)? Or maybe "deadband temperature setpoint" is more suitable here?
3. Return Air Temperature Low/High Reset Setpoint. Currently, the sub-classes for reset setpoints include registers for DAT/OAT/HWST. However, some of the BMS systems contain control blocks with a control for discharge temperature based on return air temperature.
4. Hot Water Return Temperature Setpoint (located on return pipe of a heating coil, used for freeze protection). Ontology includes "supply/discharge water temperature setpoints" but does not have "return temperature setpoint".
5. Discharge Air Humidity Setpoint. There is a bit of inconsistency here: both humidity sensors and temperature sensors/setpoints have a list of sub-classes: discharge, outside, zone etc. Though, "humidity setpoint" is a lowest subclass in hierarchy.
6. Mixed Air Humidity Sensor is missing, while ontology includes a register for MAT sensor.
7. Intake Air Temperature/Humidity Sensor (located inside the supply duct of AHU). I couldn’t find it in the ontology. Typically, an OAT sensor is used for the whole building, while IAT sensors are AHU-specific.
8. Valve Position Sensor (BACnet type 'AV', 'percent', measures the current position of a valve as a fraction of its full range of motion). Ontology has "damper position sensor", but I don't see similar register for valves. Though, there is a register called "valve command". Would it be correct to use it also for read-only values?
9. Fan/Pump Flow Percentage (indicates % of maximum fan speed, or proportion of currently active units (e.g. if 3 out of 4 cascade units are active, then register indicates 75%)). There is a register called "motor speed sensor", but it does not cover 2nd case. Also "air/water flow sensors" are available, but in my understanding, it is more related to "measurable substance" rather than to equipment operation. Please correct me if I'm wrong.
10. VFD a) It seems the current description got mixed up ('An alarm that indicates a loss of water e.g. during transport'). b) Since it includes the subclass "Heat Wheel VFD", it would be logical to add "Pump VFD" & "Fan VFD".
11. Heating Valve. The description addresses only heating coil valve ('A valve that controls air temperature by modulating the amount of hot water flowing through a heating coil'). Is there a dedicated subclass for other heating valves in the hot water distribution system (e.g. three-way valve between primary/secondary hot water loops)?
12. Differential Pressure Bypass Valve. Also, I am not sure what is the best class for this? Maybe it should be included as a subclass of a water valve?
13. Hot/Chilled Water Supply Temperature Setpoint. Currently, the most granular class is the 'supply water temperature setpoint'. Would it be valuable to add sub-classes for hot/chilled water?
14. Min/Max Air/Water Temperature Setpoint Limit. At the moment, 'min temperature setpoint limit' has the only subclass 'min/max discharge air temperature setpoint limit'. Probably, it would be useful to add another subclass for e.g. 'min/max hot water supply (discharge) temperature setpoint limit'.
15. Filter has only one subclass - Mixed Air Filter. Additional sub-classes could be added to represent more AHU configurations: e.g. intake/return air filter.
# related to schedules
16. Time Program / Schedule (BACnet type 'SCH', represents operation schedule for a certain system (AHU, radiators, etc.))
17. Holiday Calendar / Schedule (BACnet type 'CAL', contains list of vacations, i.e. indicates days when mechanical system should be off)
18. Holiday Status (BACnet type 'BV', indicates whether today is holiday or not)
19. Overwork Button Command/Status (BACnet types 'BV/BI', activates system outside scheduled time) # probably can be captured by 'On Status' from the ontology
# some common modes that are used in BMS and are used for adjusting setpoints for discharge air temperature, or secondary hot water supply temperature
20. Compensation factor based on zone temperature (BACnet type 'AV', used for adjusting reset curves setpoints for discharge air/supply water based on real-time temperature feedback from a thermal zone). Typical registers include: status of compensation mode, reference zone temperature, increase/decrease offsets or parameters (it can be fixed or dT-based (if zone temperature is colder than reference, then increase supply temperature by "K1" , or by (Tref - Tzone) * "K2")), setpoints before/after compensation regulation. Are there relevant registers in the ontology to characterize this mode? If not, maybe it should be considered as an addition to "parameter class", as these compensation factors are pretty common in BMS.
21. Compensation factor based on wind speed (same principle as above, but wind speed sensor is used for adjusting reset curve setpoints)
22. Optimal startup mode (parameters, that can override startup time and temperatures for hot water distribution loop). Typical registers include: mode status, morning temperature offset (e.g. + 20 degrees on top of reset curve setpoint), step & time-delay parameters (to define how sharp and how long would it take for temperature to get back to normal operating conditions), zone setback temperature setpoint (if temperature drops at night below "T1", then heating system automatically activates), reference morning temperature & heating constant [minutes/degreeCelsius] (used to adjust morning startup time as follows: t_new = t_schedule - (T_ref - T_zone) * heating_constant). Similar questions - are there some registers in the ontology, that I can use to describe this mode? If not, would it be valuable to include it, and to what should be its hierarchical position?
23. Discharge Air Temperature Setpoint in various modes (specific registers to indicate "different stages of a setpoint" - based on reset curve only, reset curve + compensation factor, in optimal startup mode in the morning, actionable setpoint - that picks up highest value out of the above-mentioned "preliminary setpoints")
# equipment
24. Radiators. I cannot find radiators (equipment) in the ontology, though it was in 1.0.3 version as a subclass of 'terminal unit'. Currently, there are 'radiation hot water system' and 'water distribution', but it seems to system-level points rather than points to characterize individual equipment. Was it intentional decision to remove radiators from terminal units or was it overlooked?
# relationships
25. What are the proper relationship types for specifying parameters?
Could you please elaborate on the following example to give an idea what type of relationships are meant to be used between control elements and parameters that specify their behavior. For instance:
"AHU" that serves "zone" has "heating coil" that contains "heating valve" which is controlled by "PID controller" (and has "PID parameters: gain/band/step/time"). Control variable is "valve command", process variable is "discharge air temperature", and target value for PV is "discharge air temperature setpoint". Heating coil is activated only when "dT threshold" is met for "delay parameter" time.
So how ideally these points should be related to each other?
Thanks a lot for answering my questions. Please let me know if we can contribute somehow to BRICK development.
Best regards,
Smart Building Engineer at Spectral
Gabe Fierro
Great to expand the Brick community --- especially so with such careful and
complete documentation of issues! I would love to work with you and your team
to make sure we address these issues in a way that fits your needs and helps
make Brick better for all of us. I've included my replies inline below for each
of the issues you've listed. Many of these are simple/straightforward fixes
> To begin with, as a new BRICK user I have a few questions/proposals related
> to the classification of certain data-points, and would be grateful if someone
> could address it here. Please let me know, what would it be the preferable
> communication approach - shall I post similar questions here, or use GitHub
> issues instead?
> # related to AHU & hot water distribution system > > 1. Calculated dT (BACnet
> type 'AV', shows difference between the setpoint and actual value of process
> variable, e.g. discharge air temperature sensor/setpoint). Which BRICK point
> should I use for this?
for this point? Would this be a `Delta Temperature`? It is easy enough to
create the class for this point (will have to give some thought as to which
Brick Point class it belongs under --- maybe `Sensor`?). A more general
question for this class and a few of the others you mention below is how can we
best model the relationship of a certain point (e.g. a `delta`) with the other
points it is linked to (e.g. the upper bound of a setpoint, etc)
> 2. delta-T threshold for activating & deactivating control loop. (BACnet type
'AV', 'degreesCelsius', specifies threshold to generate/abolish heating/cooling
requests sent to downstream control elements, e.g. if supply temp. setpoint
minus supply temp. measurement is higher than "threshold" → activate a certain
control loop: heating coil/or heat wheel). Would "differential temperature
setpoint" be applicable here, or it implies only for difference between two
measurements (e.g. discharge/return air temperature sensor)? Or maybe "deadband
temperature setpoint" is more suitable here?
about these two classes, I'm not sure if there is a substantial enough
difference to warrant having both. If there's additional context/usage that
you're aware of that can inform our recommendation, I'm happy to hear it!
> 3. Return Air Temperature Low/High Reset Setpoint. Currently, the sub-classes
> for reset setpoints include registers for DAT/OAT/HWST. However, some of the
> BMS systems contain control blocks with a control for discharge temperature
> based on return air temperature.
to the DAT/OAT/etc flavors
> 4. Hot Water Return Temperature Setpoint (located on return pipe of a heating
coil, used for freeze protection). Ontology includes "supply/discharge water
temperature setpoints" but does not have "return temperature setpoint".
> 5. Discharge Air Humidity Setpoint. There is a bit of inconsistency here:
> both humidity sensors and temperature sensors/setpoints have a list of
> sub-classes: discharge, outside, zone etc. Though, "humidity setpoint" is a
> lowest subclass in hierarchy.
well?
> 6. Mixed Air Humidity Sensor is missing, while ontology includes a register
> for MAT sensor.
> 7. Intake Air Temperature/Humidity Sensor (located inside the supply duct of
> AHU). I couldn’t find it in the ontology. Typically, an OAT sensor is used for
> the whole building, while IAT sensors are AHU-specific.
Intake Air Temp/Humidity sensors (or at least points labeled as such). It is
probably a good idea to differentiate between these two cases if this is a
common distinction. Is the difference between OAT sensor and IAT sensor just
how it is used? e.g. is an IAT sensor really just a copy of a single OAT sensor
for the building but associated with the AHU?
> 8. Valve Position Sensor (BACnet type 'AV', 'percent', measures the current
> position of a valve as a fraction of its full range of motion). Ontology has
> "damper position sensor", but I don't see similar register for valves. Though,
> there is a register called "valve command". Would it be correct to use it also
> for read-only values?
via the `isPointOf` relationship. `Damper Position Sensor` is a class used for
actual sensors that would measure damper position, rather than a device
register that might report the intended position. It sounds like you're talking
about the latter case, right? In this case we might want to consider adding a
`Position Status` point that captures the read-only nature
> 9. Fan/Pump Flow Percentage (indicates % of maximum fan speed, or proportion
> of currently active units (e.g. if 3 out of 4 cascade units are active, then
> register indicates 75%)). There is a register called "motor speed sensor", but
> it does not cover 2nd case. Also "air/water flow sensors" are available, but in
> my understanding, it is more related to "measurable substance" rather than to
> equipment operation. Please correct me if I'm wrong.
probably want something along the lines of `Relative Output Status`? That would
be in percentage units; we could possibly introduce different subclasses for
different kinds of relative output? Relative to max speed, max number of units,
etc --- open to ideas here.
> 10. VFD a) It seems the current description got mixed up ('An alarm that
> indicates a loss of water e.g. during transport'). b) Since it includes the
> subclass "Heat Wheel VFD", it would be logical to add "Pump VFD" & "Fan VFD".
> 11. Heating Valve. The description addresses only heating coil valve ('A
> valve that controls air temperature by modulating the amount of hot water
> flowing through a heating coil'). Is there a dedicated subclass for other
> heating valves in the hot water distribution system (e.g. three-way valve
> between primary/secondary hot water loops)?
I'm still learning a lot about how these kinds of systems are put together so
we can determine the most effective way to model it. Is there nomenclature
you're familiar with that we can base our solution off of?
> 12. Differential Pressure Bypass Valve. Also, I am not sure what is the best
> class for this? Maybe it should be included as a subclass of a water valve?
> 13. Hot/Chilled Water Supply Temperature Setpoint. Currently, the most
> granular class is the 'supply water temperature setpoint'. Would it be valuable
> to add sub-classes for hot/chilled water?
already have entering/leaving setpoint classes (what they are entering/leaving
is determined by the `isPointOf` relationship) that we can adapt.
> 14. Min/Max Air/Water Temperature Setpoint Limit. At the moment, 'min
temperature setpoint limit' has the only subclass 'min/max discharge air
temperature setpoint limit'. Probably, it would be useful to add another
subclass for e.g. 'min/max hot water supply (discharge) temperature setpoint
limit'.
> 15. Filter has only one subclass - Mixed Air Filter. Additional sub-classes
> could be added to represent more AHU configurations: e.g. intake/return air
> filter.
> # related to schedules
>
> 16. Time Program / Schedule (BACnet type 'SCH', represents operation schedule for a certain system (AHU, radiators, etc.))
>
> 17. Holiday Calendar / Schedule (BACnet type 'CAL', contains list of vacations, i.e. indicates days when mechanical system should be off)
>
> 18. Holiday Status (BACnet type 'BV', indicates whether today is holiday or not)
this kind of data. I can bring it up with the team to determine how we want to
handle this. Absolutely agree that we should figure out some way to model these
--- I just want to make sure we don't "overfit" to BACnet.
> 19. Overwork Button Command/Status (BACnet types 'BV/BI', activates system
> outside scheduled time) # probably can be captured by 'On Status' from the
> ontology
> # some common modes that are used in BMS and are used for adjusting setpoints for discharge air temperature, or secondary hot water supply temperature
> 20. Compensation factor based on zone temperature (BACnet type 'AV', used for adjusting reset curves setpoints for discharge air/supply water based on real-time temperature feedback from a thermal zone). Typical registers include: status of compensation mode, reference zone temperature, increase/decrease offsets or parameters (it can be fixed or dT-based (if zone temperature is colder than reference, then increase supply temperature by "K1" , or by (Tref - Tzone) * "K2")), setpoints before/after compensation regulation. Are there relevant registers in the ontology to characterize this mode? If not, maybe it should be considered as an addition to "parameter class", as these compensation factors are pretty common in BMS.
> 21. Compensation factor based on wind speed (same principle as above, but
> wind speed sensor is used for adjusting reset curve setpoints)
like the fit nicely under the `Parameter` class. Probably `Compensation Factor`
as the parent class and then each of the registers you mentioned as subclasses?
> 22. Optimal startup mode (parameters, that can override startup time and temperatures for hot water distribution loop). Typical registers include: mode status, morning temperature offset (e.g. + 20 degrees on top of reset curve setpoint), step & time-delay parameters (to define how sharp and how long would it take for temperature to get back to normal operating conditions), zone setback temperature setpoint (if temperature drops at night below "T1", then heating system automatically activates), reference morning temperature & heating constant [minutes/degreeCelsius] (used to adjust morning startup time as follows: t_new = t_schedule - (T_ref - T_zone) * heating_constant). Similar questions - are there some registers in the ontology, that I can use to describe this mode? If not, would it be valuable to include it, and to what should be its hierarchical position?
Parameter` though they are underspecified). Is the "optimal startup mode" a
discrete value calculated from other registers, or are you using the term as a
catch-all for these kinds of parameters?
> 23. Discharge Air Temperature Setpoint in various modes (specific registers
> to indicate "different stages of a setpoint" - based on reset curve only, reset
> curve + compensation factor, in optimal startup mode in the morning, actionable
> setpoint - that picks up highest value out of the above-mentioned "preliminary
> setpoints")
determine the current setpoint from a collection of potential setpoints?
> # equipment
> 24. Radiators. I cannot find radiators (equipment) in the ontology, though it was in 1.0.3 version as a subclass of 'terminal unit'. Currently, there are 'radiation hot water system' and 'water distribution', but it seems to system-level points rather than points to characterize individual equipment. Was it intentional decision to remove radiators from terminal units or was it overlooked?
> # relationships
>
> 25. What are the proper relationship types for specifying parameters?
location, but when parameters have to do with other points, then it feels like
we should provide some other relationship to group those points together. I
will bring this up with the Brick dev team
> Could you please elaborate on the following example to give an idea what type of relationships are meant to be used between control elements and parameters that specify their behavior. For instance:
>
> "AHU" that serves "zone" has "heating coil" that contains "heating valve" which is controlled by "PID controller" (and has "PID parameters: gain/band/step/time"). Control variable is "valve command", process variable is "discharge air temperature", and target value for PV is "discharge air temperature setpoint". Heating coil is activated only when "dT threshold" is met for "delay parameter" time.
>
> So how ideally these points should be related to each other?
AHU feeds HVAC Zone
AHU hasPart HeatingCoil
heatingCoil hasPart heatingvalve
heatingvalve hasPoint valve_command
heatingvalve isControlledBy controller
controller hasPoint proportional_Band_Parameter
controller hasPoint step_parameter
controller hasPoint time_parameter
controller hasPoint gain_parameter
controller hasPoint valve_command (same valve command as above)
controller hasPoint discharge_air_temperature_sensor
controller hasPoint discharge_air_temperature_setpoint
(optional, but often included)
AHU hasPoint discharge_air_temperature_sensor
AHU hasPoint discharge_air_temperature_setpoint
We don't currently capture any of the actual "logic", e.g. when the heating
coil is activated.
--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/dbcd9e93-0e23-43ee-8272-15206de86638n%40googlegroups.com.
Ville Ilkkala
> # related to schedules
>
> 16. Time Program / Schedule (BACnet type 'SCH', represents operation schedule for a certain system (AHU, radiators, etc.))
>
> 17. Holiday Calendar / Schedule (BACnet type 'CAL', contains list of vacations, i.e. indicates days when mechanical system should be off)
>
> 18. Holiday Status (BACnet type 'BV', indicates whether today is holiday or not)
> this kind of data. I can bring it up with the team to determine how we want to
> handle this. Absolutely agree that we should figure out some way to model these
> --- I just want to make sure we don't "overfit" to BACnet.