It's something I miss from Lon standards (nvi, nvo, cp and nci) were clearly identifying the points so we could know what we could use them for. (it's the only thing I miss about Lon ;-)

In BACnet and other standards (like N2), we cannot count on that little trick to classify tags inside a list of tags.

A good example is any new device you discover on a station (I work with Tridium stuff... think Brian know them well... :0P) You see the list of name... but you have to refer to the manual to knwo exactly what points you can write (volatile or EEPROM ones...) what points are only readable, etc.

How do you deal with that ?

Should we (would it be useful to) use a term to identify a writable point ?

I'm curious to know what you think about that.

Hi Christian, thanks for helping us out for Haystack!

Since we are purely modeling data, I don't think haystack will really get into making setpoint/writable changes per se. But it seems useful to me for the model to capture which points are writable versus which ones are readonly sensors.

In oBIX we did this with the writable attribute. So that might be a good pattern to use for Haystack. Any point may be tagged with the writable marker tag to indicate that the point is an actuator or configuration point.

Comments?

Do you make a distinction between "volatile" points and "cp" kind of points ? It's really useful to know at what frequency you can write to a variable.

I would be inclined to not go that deep in the model until we were sure that level of detail had value for they ways people will use Haystack. At the enterprise level of oBIX for example that level of detail was never necessary.

It's a problem I see with field devices (bacnet, Lon, or N2). Memory registers are not always defined the same and there are some variables that require to be re-written on a regular basis to be sure they are correct. Other, need to be written only if necessary (ex. 100 000 cycles EEPROM...)

When programming HMI stations, I often need to search for volatile points to modify the write policy of the used driver. From my point of view, it's a really useful thing to know.

But I understand your point. From a oBix point of view, it seems that we don't need to care about that.

It's actually a very specific need for field controllers.

Being able to distinguish setpoints is definitely valuable.

I've noticed there are some tags defined with the "Sp" suffix, such as outsideFlowSp and zoneTempSp. There are quite a few tags that do not have a setpoint counterpart, however, at least not yet. There is also the writable marker tag, as Brian mentioned, which could be used to denote a setpoint.

My question is: what convention are we going to follow? Define individual setpoint tags for the various types of setpoints or use a marker tag? Seems like the current answer is both, probably because there are some very common types of setpoints that warrant their own tags.

Would it make more sense to have a setpoint marker tag? A setpoint is always writable, but is a writable point always a setpoint?

My vote is to go with a seperate setpoint marker tag. There are a lot of points out there that have setpoints and this would knock down the amount of tags out there by not having to have the same tag name with the "Sp" suffix.

To also cover the issue of other types of points (i.e. inputs and outputs) I believe we could add a few other standard tags similiar to setpoint. My initial thoughts are to have the following standard tags.

• setpoint - Marker Added to a point that is a numeric setpoint.
• command - Marker Added to a point that is an output command.
• sensor - Marker Added to a point that is a sensor input.

These 3 tags help differentiate numeric setpoints and sensors, numeric commands and sensors and also boolean commands and sensors.

Using this model takes full advantage of the tagged database as well because it is very simple to find the exact point you want using a simple AND statement.

• discharge temperature setpoint: dischargeTemp and setpoint
• fan command: fan and command
• fan status: fan and sensor
• chilled water supply temperature: cwSupplyTemp and sensor
• chilled water supply temperature setpoint: cwSupplyTemp and setpoint

I believe these 3 tags would be applied to at least 90% of the typical points in a database and cut down on the total amount of tags dramatically.

Thoughts?

@Joe - your proposal is interesting. I think the idea of using multiple tags to fully describe a point's role is probably the right direction and the way things seem to be heading.

What would be the difference between setpoint and command? Is it only the difference between analog and digital? I would think just setpoint would suffice wouldn't it?

My main concern with overloading a given tag like dischargeTemp is that it would absolutely require all models to add the sensor tag. Because otherwise looking for just dischargeTemp would fail. So its a pretty big breaking change.

My initial thought was that a setpoint is a virtual point in the system and not actual I/O points. This would include supply temperature setpoints, air pressure setpoints, etc...

My initial thought was that a command is a physical output. Fan command, damper position, valve position, etc... command and sensor points can be both analog or digital. To determine if a point is analog or digital it would require looking at the kind tag.

The tag names I originally proposed could also easily take their close synonyms:

• command -> output
• sensor -> input

I agree this type of proposal, of overloaded tags on points, would definitely involve applying them to all models.

I have been following this discussion for a while and would like to suggest the following;

Command: The term is used specifically to initiate a change in the designated target. This usually means turning something "On" or "Off",(or any of the alternate equivalent associated engineering units) initiating a sequence, or executing a manual emergency procedure. Commands are sent to Output devices only, which have a capacity to accept and execute the command received and reflect that change back to the commanding device. Commands are also sent to analog output devices where it may be desired to position a motorized output device to a specific position (such as 50 %)

Sensors are always inputs, almost exclusively analog or numeric values. These inputs are read frequently (up to several times per second) and are seldom static (unless measured variable is also with little change).

Digital inputs have only two states to report on, "contact Open" or "contact Closed". Field changes are most often reported by field device using COS/COV (Change of State/ Change of Value) services, Present state values along with appropriate "Engineering values, may be read from device at any time.

Setpoint; A value that may be calculated from another process or a value that has been predetermined to be the objective of the associated control process. Setpoint values may be writable from various sources. The last change will be the present value until written to again. Requires frequent updates. A setpoint is always associated with an analog output or a process controlling an output.

Earlier in the discussion I noticed the term "volatile" points. I would suggest that the term "virtual or pseudo"" might be more recognizable in these discussions. Virtual or pseudo points are in software only, usually react as real points but without associated hardware. There are limitless uses for these values in local field controllers

Interesting but I must disagree with your last statement.

On field controllers we face 2 kinds of setpoints.

First kind : setpoint you change once a while (ex: spaceTempSP)

Second kind : setpoint that you could change regularly (ex. reset a minimum position of a fresh air damper regarding returnCO2)

The second one needs a setpoint, based in the RAM of the controller that you can write forever if you want... if not, you will reach a time where you wrote over 100k times on it and the memory of the controller will be dead. For what I know, those setpoints are "null" or "Nan" at boot, you have to link something to them to get a value. Some controllers have a kind of "default" value for those particular setpoints.

Let's think of another example : outdoorTemp

If you want to send this information to a field controller, you know that, for the life of the controller, you will write to this variable many times a day... 100 000 writes to an EEPROM will soon be reached, even if there's a certain differential between each written values.

Maybe volatile isn't a good name. But I think it would be valuable to know "how many times" I can write to a variable. Virtual, or pseudo aren't covering this issue.

It's really an "electronic", "electrical" issue...

While I am not the moderator of this project, the examples you have suggested are well beyond the scope of this discussion and the extent to which this standard can adequately address. The process of using tags and quantity of them must not be determined by the hardware a supplier chooses to use (as in number of writes an EEPROM will reliably accept). Use of standards elevate the data from the hardware so as to become "standard" in application and remove the hardware dependency from the equation. Proprietary systems in many cases are chip dependent.

Well, you certainly see that I'm most on the application side vs "standard creation" side. If this is too out of scope I will understand.

From my point of view (user, integrator, programmer of custom controllers), it would be a nice to have...

I also understand that this concern is more of a end-device on a serial bus (like BACnet MS/TP, or Lon)... You won't need that in OBix or BACnet/IP.

Finally, don't hesitate to bring me back on track if you see that I'm running out of range ! :-) No need to be moderator !

Have a nice weekend

Great discussion, let me to try to clarify the major points under discussion as I see them:

Durability

At the low level in devices, there are different ways to store a given piece of data. In simple terms a piece of information is transient (stored in dynamic RAM) or persistent (stored to a durable media that survives reboots). Some durable media such as Flash have limited write cycles.

In general this rarely matters to most applications except when the application is writing to the data value such as changing a setpoint or commanding an actuator.

The scope of Haystack is open ended, but we created it primarily for modeling data for analysis. I don't know of any use case where analytics would make use of knowing the memory technology used to persist (or not persist) a data value. If there was an analytics use case or a non-analytics use of Haystack that made it important, then the issue should be explored further.

Commands vs Setpoints

If I understand what Joe was thinking, we could make the distinction as "hard" points and "soft" points. Hard points are directly related to a sensor or actuator. Soft points are software only points used as part of a control sequence and only indirectly related to actuator output (such as thru a PID loop).

But lets loop back to around the idea of overloading a given tag and then adding sensor, command, or setpoint to it. In the case of sensor and setpoint these are often paired. I decide what I want my zoneTemp to be and then I measure it via a sensor to create closed loop control. Sensors are often paired with a setpoint.

But in the case of actuator/commands this pairing doesn't happen. Consider a fan, damper, or pump. We don't ever really pair a fan, damper, or pump to a sensor per se. There might be a flow sensor, but you rarely think of calling a flow sensor in a duct a "fan" or a flow sensor in a pipe the "pump". In fact much of analytics is about using sensors to figure out if the actuator is working properly (is the fan/pump running? is the damper stuck?).

So let me ask this question: is there any "command" point where we need to overload the tag to indicate sensor vs command point? I can't think of anything. If that is the case, then the problem can be simplified to sensor vs setpoint (which is still an open issue).

Single Tag vs Multiple Tags

Perhaps one of the most important issues touched by this discussion is the basic philosophy of whether to capture the intent in one single tag or use multiple tags. In this specific case we can consider two options for a point like zoneTemp:

• Single tags: zoneTemp and zoneTempSp
• Multiple tag: zoneTemp paired with sensor or setpoint

Both have pros and cons. The single tag model is simpler and more robust for queries to express intent. You would rarely look for either or, but would always be looking explicitly for one or the other. Using multiple tags is more elegant and avoids "tag explosion".

After thinking more about this, I'm thinking our current approach of using two tags with the Sp suffix is the right direction. My logic is sort of based on this thinking: if I would use the term in the point name to make it clear then it probably belongs in the primary tag name. I'm also trying to extroloate this to the proposal for dealing with 3-phase current/voltage/power (capture in one tag or use supporting tags).

So those are my current thoughts. At the very least, the action item from this discussion needs to be a final decision on convention for sensor vs setpoint. And there might still be discussion around need for writable/memory technology. But so far, this has been great - I feel my thoughts become more clarified as the discussion progresses.

Brian, in reference to your last post, I am having difficulty understand your use of the adjective "durability" In my understanding the word is used predominantly to convey the long term resistance of a physical material to wearing out. e.g. as might be used in relation to hard substances (a physical material). The Haystack project is not discussing physical materials and therefore not something that is durable. Please help me understand your comment.

Commands vs Setpoints; In your comments you remarked that one of the principle uses of the work the Haystack project is targeted is that of analysis of the data collected from buildings. With that in mind, would there ever be a case for writing to the field controllers to change how the systems function? Realistically I do not believe writing to the hardware or the field controller software. If so then there would not be any compelling reason to include any commands in the Haystack definitions. Setpoints are a different matter. Setpoints are used in present systems in a variety of ways. As mentioned setpoints are sometimes associated with a sensor which is being used as the primary input value for a control loop. This however is not the only approach used. Analog Outputs (points that re-position valves, dampers or speed control for variable speed motors driving fans or pumps. In existing products of today, the analog output object (software definition of values or properties of the control loop parameters) includes the setpoint or setpoint reference for the control loop in question. It should be noted that only selected sensors are used as inputs to control loops and also that an average value of several sensors are used to be the primary input to certain control loops.

My preference in the use of setpoints is to associate the setpoint with the output object. In this manner the setpoint value is always found with the output object driving the device being controlled. In most of today's products, the output object also includes the reference to the input sensor used the measure the media being controlled.

I believe that I have also indirectly coveredd the subject of multiple tags.

I think Durability was used as a synonym of lastingness or sustainability

Definition of durability: The property of fulfilling its designed purpose and for retaining its essential properties over a long period. http://granddictionnaire.ca

===

This said, I think that if we do not add setpoint tags, we are missing an important point in setting up an analysis tools in a BAS system.

If we think about how analysis is made in a building, we can rapidly come to the fact that we need a system, platform, station, etc... Give it the name you want, but we need a kind of computer that will talk to all devices in the building and gather all the informations of the building.

If you want to be able to browse the databse of this system, you will need a structure, somewhere to start to be able to order/categorize all the information.

It could be very difficult to modify an existing system to fit a standard like Haystack... That's why I think that the standard should be used as the standard of naming/organizing/ordering things inside your BAS system, from the beginning of the project.

I'm actually working a lot with Tridium stuff as I said so I'll talk of what I know. If you organize your controllers/points name them properly, add tags (string slots to add descriptions, systems, unit names, etc...) you can then use database requests (BQL) to find everything you want. (ex. Find all coolingDemand from all VAV boxes under the cooling unit named AC-1)

So, if you build from the beginning, using a good standard, you will have tags, standard names for everything, including setpoints.

Because even if you do not want to modify setpoints, maybe one would want to grab a list of all room temperatures with their respective setpoints. You need a way to find all the information.

=== Finally, there are some setpoints that can hardly be associated to an output without leading to some confusion. One quick example would be an output that could be driven from different PID loops... like a cooling valve in a AHU that could be used to cool AND dehumidify. returnHumiditySp and spaceTempSp could not be associated directly to the output without leading to some sort of confusion (wich one wins, when?).

Another example would be setpoints used to reset other setpoints (like a roomTempSp resetting a dischargeTempSp). There is no output involved.

I think we can't say that all setpoints are associated to an output.

With reference to the use of the term durability. My point was that there are many other words which might convey the intent of Brian's previous comment better. Wikipedia offers therm (ACID) with reference to database data, which is the actual subject of this discussion.

With respect to setpoint; I was not suggesting that the tag not be used but rather it's association with data other than the sensor input. I would by default look at the control loop process, which would contain much more data useful for the analysis purpose. Typically the measured variable (sensor input value), setpoint, the output signal (indicating the ability of the control loop to continue to control, in range or not). PID values are also available where implemented. Reading one set of values is much simpler ans expedient than reading several independent values

Again this would be my preference.

Interesting topic, indeed. I'd like to chime in on the Single Tag vs. Multiple Tags issue, to second Christian's statement above that having a separate tag for setpoints allows a quick query to provide all the information, such as which points have respective setpoints, or not.

Regarding the setpoint's role in the control loop process, it appears there needs to be a connection between the controlled point and the setpoint. Perhaps a controlPointRef type of tag could be used to quickly assess connect the setpoint with its associated control point sensor.

Being able to query an entire site, zone, or piece of equipment for every setpoint/sensor pair which the controlled point is out of range of the setpoint would be tremendously powerful.

I have pulled the single tag vs multiple tag debate into its own discussion topic 25.