We have a couple of use cases involving sensors that are "aggregated" into "soft" sensor points.
In one case, we have lights (in a lightsGroup), which may have occupancy sensors. When multiple (constituent) occupancy sensors are placed in a single lightsGroup, it's common to "aggregate" these occupancy sensors as a combined entity - when occupancy is detected on ANY one occupancy sensor, we have occupancy; when occupancy is detected on NONE of the occupancy sensors, we do not have occupancy. What is desirable here is a tagging scheme to represent and be able to distinguish the constituent occupancyIndicator state and the aggregate occupancyIndicator state.
On a similar basis, temperature sensors could have this characteristic. When multiple (constituent) temperature sensors are intended to be used for say, thermostatic control for one conditioned zone, it's possible to "aggregate" these temp sensors so that say, an average (or some other function, such as min or max) of the temperature values is used for the purpose of thermostatic control. Again, it's desirable to be able to tag and distinguish between the constituent temp sensor points and the aggregate temp sensor point.
A strawman proposal for a tagging scheme to represent this is presented below. This would work, but has issues. I'd be interested to hear about alternatives, especially if folks have had to do something similar.
+ lightsGroup equip
+ occupancyIndicator group sensor point # aggregate occupancy indication (for the entire lightsGroup), group is not a standardized tag
+ occupancyIndicator sensor point # constituent occupancy indication (for each individual OS)
…
+ occupancyIndicator sensor point # constituent occupancy indication
+ hvac equip
+ zone temp sensor point # average temperature sensor value (from all temp sensors in zone)
+ temp sensor point # constituent temp sensor value in zone
…
+ temp sensor point # constituent temp sensor value in zone
Brian FrankWed 13 Apr 2016
We have decided over time that modeling these distinctions is best done using tags that explicitly denote the differences on both sitdes. What we try to avoid is that omitting a tag implies semantics. So this is a case where we want two terms that work in opposite to model this situation. I think group is too generic, although you used the term aggregate which actually works well (not sure what the opposite term is for the other sensors would be though). Maybe aggregate and aggregated? Collective and collectivePart?
Jason ChoongFri 15 Apr 2016
Okay, that's great guidance, Brian. As for the actual tags, how about aggregated and component (or perhaps aggregatePart, cueing off your collectivePart idea). The issue with component (or other simple terms like "part") is that they may end up being tags used for other purposes. So, the example above then would look something like this:
+ lightsGroup equip
+ occupancyIndicator sensor aggregated point # aggregate occupancy indication (for the entire lightsGroup), group is not a standardized tag
+ occupancyIndicator sensor aggregatePart point # constituent occupancy indication (for each individual OS)
…
+ occupancyIndicator sensor aggregatePart point # constituent occupancy indication
+ hvac equip
+ zone temp sensor aggregated point # average temperature sensor value (from all temp sensors in zone)
+ zone temp sensor aggregatePart point # constituent temp sensor value in zone
…
+ zone temp sensor aggregatePart point # constituent temp sensor value in zone
Jason Choong Tue 12 Apr 2016
We have a couple of use cases involving sensors that are "aggregated" into "soft" sensor points.
In one case, we have lights (in a lightsGroup), which may have occupancy sensors. When multiple (constituent) occupancy sensors are placed in a single lightsGroup, it's common to "aggregate" these occupancy sensors as a combined entity - when occupancy is detected on ANY one occupancy sensor, we have occupancy; when occupancy is detected on NONE of the occupancy sensors, we do not have occupancy. What is desirable here is a tagging scheme to represent and be able to distinguish the constituent occupancyIndicator state and the aggregate occupancyIndicator state.
On a similar basis, temperature sensors could have this characteristic. When multiple (constituent) temperature sensors are intended to be used for say, thermostatic control for one conditioned zone, it's possible to "aggregate" these temp sensors so that say, an average (or some other function, such as min or max) of the temperature values is used for the purpose of thermostatic control. Again, it's desirable to be able to tag and distinguish between the constituent temp sensor points and the aggregate temp sensor point.
A strawman proposal for a tagging scheme to represent this is presented below. This would work, but has issues. I'd be interested to hear about alternatives, especially if folks have had to do something similar.
Brian Frank Wed 13 Apr 2016
We have decided over time that modeling these distinctions is best done using tags that explicitly denote the differences on both sitdes. What we try to avoid is that omitting a tag implies semantics. So this is a case where we want two terms that work in opposite to model this situation. I think group is too generic, although you used the term
aggregatewhich actually works well (not sure what the opposite term is for the other sensors would be though). Maybe aggregate and aggregated? Collective and collectivePart?Jason Choong Fri 15 Apr 2016
Okay, that's great guidance, Brian. As for the actual tags, how about aggregated and component (or perhaps aggregatePart, cueing off your collectivePart idea). The issue with component (or other simple terms like "part") is that they may end up being tags used for other purposes. So, the example above then would look something like this: