For most building automation systems there are several standard point types (BI, BO, BV, AI, AO, AV, MV) and I've marked in parenthesis how I've been converting this information into two categories and related tags. I am struggling to define how tags can be automatically assigned for "software"/"virtual"/"calculated" points (represented by the V) when they are not a true setpoint. I would prefer to either not apply any of the standard point type tags (sensor/cmd/sp) or to create a new point type tag of "virtual".
Signal Type: A = analog (number), B = binary (bool), or M = multi-state (usually str) Signal Direction: I = input (sensor), O = output (cmd), or V = virtual (sometimes sp)
Example 1: For an AHU, when outside air flow station is used, it is common to see a "sensor" measuring the air flow velocity (ft/m), and a separate "calculated"/"AV" point is generated from that along with adjustment factors and cross-sectional area to convert the measured value to the units of cfm. This type of airflow is also often controlled to a setpoint for ventilation requirements. The flow is more valuable to me then the velocity, but it is useful to know this is not a direct measurement.
I had been automatically adding a tag of "sp" for all AVs, but this made this point indistinguishable from the true setpoint. If I reserve the "sp" only for true setpoints, then I would be unable to generally assign an AV point type to "sensor" or "cmd" without causing other potential conflicts or confusion. While it is reasonable to assign this particular point as a sensor, it is much more complicated logic to identify that this was appropriate and other AVs deserve a different choice.
Example 2: Sometimes a "software"/"AV" point with a meaningful engineering unit (ex: %) is calculated and represented on graphics for valves and dampers while a different AO point with less meaningful units (V/A/psi) is actually output for the device control. It is not too uncommon to see both a "cmd" and "sensor" for the actual device to help indicate and prevent significant control problems.
Again, I think "sp" is inappropriate for this type of more intuitive engineering unit AV point, but adding "cmd" or "sensor" could cause a conflict with the true input and outputs.
Do you agree that points should be allowed to not have sensor/cmd/sp or that we should create a new tag?
Jason BriggsThu 21 Nov 2013
Chris.... I think we want to keep points into these 3 categories.
I think the term sp, was probably not the best one to pick. It confuses people on thinking it's just a setpoint. I think it should've been vp for virtual points.
In bacnet it's nice cause with those 3 tags + kind you can figure out if the bacnet point is a ai,av,bi,bo,bv,ao,mv,etc...
My vote is to keep all points defined by only those 3 tags. But I'm not opposed to renaming sp, to vp. Although if we just make the docs better about explaining what a sp really is that might be ok too.
Also, maybe we should also have a tag called setpoint, for actual setpoints???
Brian FrankFri 22 Nov 2013
I am not sure "virtual point" is the best term. Rather maybe a better term might be "soft point" - which also maps to sp nicely :)
Christopher BensonFri 22 Nov 2013
Brian, I've never particularly liked the term "virtual", though I think it is the least ambiguous V option to align with BACnet point types. BACnet actually refers to these as "value", though isn't every number a value?. I also like the terms "soft point" or "software point".
Jason, I think we're in alignment of use and keeping things simple. To succinctly reiterate my points above, setpoints are one of several types of virtual/software points and I believe it is an important difference to distinguish in the Haystack model. If a change can be agreed upon, considering the existing documentation and applied use, I believe it would be simplest to do one of the following:
1) Keep "sp" defined as setpoint and continue use for all points designating a control variable. Change the third category of point types to "virtual", "value", "vp", or "softPoint".
2) Update the documentation for point categories and tagging models to redefine "sp" as virtual/software point. Replace "sp" with a new tag "setpoint" for all tagging models designating a control variable.
Christopher Benson Thu 21 Nov 2013
For most building automation systems there are several standard point types (BI, BO, BV, AI, AO, AV, MV) and I've marked in parenthesis how I've been converting this information into two categories and related tags. I am struggling to define how tags can be automatically assigned for "software"/"virtual"/"calculated" points (represented by the V) when they are not a true setpoint. I would prefer to either not apply any of the standard point type tags (sensor/cmd/sp) or to create a new point type tag of "virtual".
Signal Type: A = analog (number), B = binary (bool), or M = multi-state (usually str) Signal Direction: I = input (sensor), O = output (cmd), or V = virtual (sometimes sp)
Example 1: For an AHU, when outside air flow station is used, it is common to see a "sensor" measuring the air flow velocity (ft/m), and a separate "calculated"/"AV" point is generated from that along with adjustment factors and cross-sectional area to convert the measured value to the units of cfm. This type of airflow is also often controlled to a setpoint for ventilation requirements. The flow is more valuable to me then the velocity, but it is useful to know this is not a direct measurement.
I had been automatically adding a tag of "sp" for all AVs, but this made this point indistinguishable from the true setpoint. If I reserve the "sp" only for true setpoints, then I would be unable to generally assign an AV point type to "sensor" or "cmd" without causing other potential conflicts or confusion. While it is reasonable to assign this particular point as a sensor, it is much more complicated logic to identify that this was appropriate and other AVs deserve a different choice.
Example 2: Sometimes a "software"/"AV" point with a meaningful engineering unit (ex: %) is calculated and represented on graphics for valves and dampers while a different AO point with less meaningful units (V/A/psi) is actually output for the device control. It is not too uncommon to see both a "cmd" and "sensor" for the actual device to help indicate and prevent significant control problems.
Again, I think "sp" is inappropriate for this type of more intuitive engineering unit AV point, but adding "cmd" or "sensor" could cause a conflict with the true input and outputs.
Do you agree that points should be allowed to not have sensor/cmd/sp or that we should create a new tag?
Jason Briggs Thu 21 Nov 2013
Chris.... I think we want to keep points into these 3 categories.
I think the term sp, was probably not the best one to pick. It confuses people on thinking it's just a setpoint. I think it should've been vp for virtual points.
In bacnet it's nice cause with those 3 tags + kind you can figure out if the bacnet point is a ai,av,bi,bo,bv,ao,mv,etc...
My vote is to keep all points defined by only those 3 tags. But I'm not opposed to renaming sp, to vp. Although if we just make the docs better about explaining what a sp really is that might be ok too.
Also, maybe we should also have a tag called setpoint, for actual setpoints???
Brian Frank Fri 22 Nov 2013
I am not sure "virtual point" is the best term. Rather maybe a better term might be "soft point" - which also maps to
spnicely :)Christopher Benson Fri 22 Nov 2013
Brian, I've never particularly liked the term "virtual", though I think it is the least ambiguous V option to align with BACnet point types. BACnet actually refers to these as "value", though isn't every number a value?. I also like the terms "soft point" or "software point".
Jason, I think we're in alignment of use and keeping things simple. To succinctly reiterate my points above, setpoints are one of several types of virtual/software points and I believe it is an important difference to distinguish in the Haystack model. If a change can be agreed upon, considering the existing documentation and applied use, I believe it would be simplest to do one of the following:
1) Keep "sp" defined as setpoint and continue use for all points designating a control variable. Change the third category of point types to "virtual", "value", "vp", or "softPoint".
2) Update the documentation for point categories and tagging models to redefine "sp" as virtual/software point. Replace "sp" with a new tag "setpoint" for all tagging models designating a control variable.
Qinpeng Wang Fri 23 Feb 2018
Has this been resolved on the sp vs setpoint?