One piece of the ESI proposal which I'd like to break out first for discussion is the idea of adding a fourth ovr category to points to complete sensor or cmd or sp. I've been giving this a lot of thought lately, and I'm not sure I really like the idea of creating two points to model what is effectively one point and its a sub-piece of meta.

This sort of use case seems to beg for the introduction of first class history flags so that we can just make override state a bit flag on the trended items of the command point. If we compare the two options with VFD fan command status:

1. Adding ovr would require two points - one would be fan cmd and the other would be fan ovr. The cmd point would be 0% to 100% and the ovr point would be boolean indicating if the command was being driven by a manual override.
2. With history flags there would be one fan cmd point, but the history data would include an optional flag indicating if the logged timestamp/percent pair was in an manual override condition.

Which direction would everyone prefer?

My choice would bee for two points, primarily because I don't follow your second choice and if in a historic file, how would the flag be displayed when looking at the data being received from the point.

I think we need to ask this question?

Is ovr a real point? IE... Some controllers have a manual switch on them that you can read if it's in auto or manual. If that is what we are calling ovr, then I would agree that another point might make sense.

So I suggest this:

If a controller has a status flag that says if the do is in manual, then go ahead and create a point for it. Let's say the point name is Supply Fan, then go ahead and add these tags below:

dis: Supply Fan discharge air fan sensor ovr

So, if the point is physical, then it should have the sensor tag, and the ovr tag.

If you just want to know if a user put the point in override from the front end, then the server should keep track of that. Meaning, we don't need a tag called ovr.

Those are just my thoughts,

Jason has raised a good point,some systems do have a local manual override switch and it would be wise to indicate it as a separate point. It may still be valuable to know if an operator has used a high priority command to override any logic control. In this case a second point would be necessary. In this later case there could also be the local manual switch. Would this mean a third point?

Just to share a real life case.

I've worked with lonworks devices that had :

example for Analog Output

• nvoAO1 : wich was the actual value of analog output 1
• nviOvrdAO1.state : a writable enum with 2 states ( auto, manual)
• nviOvrdAO1.value : if in manual, analog value will match this value

example for Binary Output

• nvoDO1 : actual state of binary output 1
• nviOvrdDO1.state : enum with 4 possible states ( Auto, Off, On, Pulse)
• nviOvrdDO1.value : if in pulse, will modify duty cycle of pulse

in that particular case, pulse refer to a triac output that will allow a kind of PWM to modulate a heater for example.

In bacnet, as overrides are done directly on the output variable with an priority of 8 or 1... I can't figure how we could tag an override...

Christian: In BACnet the override you are referring to is not the same as the ones we have discussed so far. To know what the override or priority setting is, you have to read the priority level that the original command was issued at. It could have been overridden for many various reasons including a level 1 priority which is usually reserved for an extreme emergency. Operators seldom have authority to set a value higher that 8 out of the range of 1 to 16(16 being the lowest and 1 is highest),16 is superseded by any other priority level above 16. The priority level does not interact with the hardware switch referred to earlier. The hardware switch has ultimate authority over any software initiated action.

Jason Briggs earlier comment " dis: Supply Fan discharge air fan sensor ovr". Just what does this string represent, I am confused, what is an "air fan sensor" and for what purpose would it be overridden? If it is a fan status then the status is not the point to be overridden, it should be the fan BO point that needs to be overridden for safety purposes. Please explain.

Sorry Winston, I just put that text in trio format, and it got formatted wrong.

Here is what the tags would look like

• fan
• discharge
• air
• sensor
• ovr

This would be the tag that exists on a controller that has a physical knob on it, and if you want to monitor the status if someone goes in the field, and physically turns the relay on. For example: Distech controllers have these option on them.

What I'm saying is that I agree with the ovr tag, but only in this type of situation. I don't think it's a good idea to create another point just to see if someone turned it in override from a front end computer.

Does that make sense?

The reason I choose to use the fan, discharge, air, and sensor tags, is because in this example I wanted to show what a Supply Fan Override point would look like. The reason it has a sensor tag, is that a sensor tag represents an input, and technically the override knob is a sensor(This is debatable, and I'm not stuck on this, maybe it should be cmd instead of sensor).

From my point of view, an override is any type of user action that will bypass the sequence programmed inside a controller.

Physical switch, distinct ovr variables, command @8 in bacnet, etc...

How you do the override is not important... the result is that the sequence won't be operating as programmed.

Is this what we want to tag when thinking about Ovr ?

Jason I think we are in agreement about the manual switch in the controller cabinet and since it is independent of the logic it needs to be monitored. I am aware that several controller manufacturers offer the switch as part of their product line. For owners who have knowledgeable staff this is a good backup device, however as so often happens human memory being what it is switchs get left in the wrong position, thus the need to monitor. The other half of this discussion has been about points being "disabled" (a very specific override by another name) for various reasons, none of which may be valid a week latter. Being able to detect and take action to put a system back to normal is the point of our debate. In BACnet points that are disabled are flagged and would be reported as such to any user interface. To me at this point in the discussion there would be no value to add another point to read what is already available information. Disabled points do not need another point to indicate they are disabled, even though for input points they can be disabled and yet still display fixed data. Christian has also indicated the need to know if points are disabled. Does the above discussion help with your concerns?

Brian this is one of the few times I'll disagree with you but I happen to agree with Christian and Winston's first comment.

This is something I've grappled with on every single SkySpark site I've deployed.

It's not just common, it is standard practice for us to have a separate point to override a program.

For example, an AHU outside air damper will have the standard point to command it, in Haystack we would model that as {outside, air, damper, cmd}. We also have a second point to override the position of the damper.

This is not a piece of meta-data it is a point in Niagara. Picking up on where this point originates from, it doesn't really matter, hard-wired switch or "soft" point. It still overrides the program. The issue I see is that it is a separate point, not meta-data.

I understand BACnet and LonWorks in some cases treat them differently. In Lon overrides are commonly specific points where as in BACnet they are meta-data. However we also have systems where in BACnet the override is a specific point.

Furthermore, detecting overrides and when they occur, and how long they occur for is a first class piece of information in my view. In our experience overrides are set and then forgotten all too often and should be treated with a high priority of things that need to be communicated.

Also, I don't agree that the "ovr" point would be boolean. An override is specified with a value and the point we are using as the override will have it's own history. Whether it be damper position, chilled water setpoint, discharge air setpoint or something else, the override is a value not just a state. The value may be true or false but that is still a value.

I'm absolutely +1 for an "ovr" tag. If such a tag can be supplemented with further meta-data modelling and capturing further information in histories then fantastic. However this is something that happens in practice in the real world and cannot be ignored.

Richard--- Great points, I totally agree with you that this is needed.

Here is the main question..

Should we create a new tag called ovr that is in place of sensor, cmd, sp, or should we have ovr go along with sensor, sp, and cmd

My thoughts are that for sure we should have a new tag called ovr, but I think you should make this an adder to the existing sp, sensor, and cmd tags.

The reason for the ovr tag in the proposed standard is exactly as Richard has outlined. There is often a completely separate point in the BAS which is not just boolean overridden/not overridden. This point contains the value that the target point is being overridden to and is typically a null value when inactive.

Secondly, regarding Jason's question, I believe that the ovr tag should be added in place of one of the "point type" tags: sensor, sp, or cmd. Including both a sensor and ovr tag would require all sensor queries to include and not ovr.

So it sounds like most people think override is a point in its own right, not meta-data on a standard cmd point. My personal thought is that this is odd since in the end a given piece of equipment like a fan is either on or off even though it can be commanded many different ways (with physical or software overrides). So we are just describing why it is on or off. But seems to be pretty broad consensus to have overrides as a separate point, so lets pursue that design...

What is the kind of an override point? Nick you suggested it was true or null? I think it might be more consistent and easier to model if we said it was kind=Bool point and true meant override was in effect and false that it was not override.

Do recommend that an ovr point always be paired with a cmd point?

Guys I think it's important that we don't try to have tags that fit every single possible scenario in HVAC. Remember sometimes custom tags work just fine. If we make this too complex, then people won't use it. The goal is to be able to hit most use cases, we don't want to turn this project into a huge spider web of tags.

Just my 2 cents. (Maybe this scenario is fine, I just think it's important to not try and model every single possible scenario)

Brian, this is for information at the moment.

In BACnet, most physical points and many virtual/pseudo points all have the possibility of being in an override state. These are property Status Flags with following options: From BACnet Standard 2008. 12.3.7 Status_Flags This property, of type BACnetStatusFlags, represents four Boolean flags that indicate the general "health" of a point.

The four flags are

{IN_ALARM, FAULT, OVERRIDDEN, OUT_OF_SERVICE}

Input points when overridden may be assigned a value which will be displayed as the Present Value of the point. Without the Status Flag state the data will look normal except static.

In this case the status flags must be included with the Present value read or get function. It is then up to Haystack to take appropriate action.

Your request that cmds be paired may be moot.

Jason, I agree simple is better, also having a solid foundation is essential. Best to have the basics before building a tower on it resulting in babel!

I'm leaning towards what Nick was saying. If you combine ovr and sensor or cmd it is going to lead to complicated queries where we want to exclude override points.

To try and keep this short I'll go with an example as to what I see working. Taking from my earlier post an outside air damper point. I believe the Haystack tag definition would look like:

{point, outside, air, damper, cmd, kind:"Number", curVal:0%}

whereas the Haystack definition of the override might look something like

{point, outside, air, damper, ovr:true, kind:"Number", curVal:75%}

an override for a boolean point could look something like

{point, outside, air, damper, ovr:true, kind:"Bool", curVal:true}

in these cases the ovr tag specifies a record as being an override point but also captures whether the override is active. I don't see this as being overly complicated, and to my way of thinking solves the problem by capturing the state of the override, the override value and the fact that an override point exists.

This leads to simple queries to find all active override points:

readAll(ovr)          // finds all override points
readAll(ovr == true)  // finds all active override points
readAll(ovr == true and kind == "Bool" and curVal == true)  
readAll(ovr == true and kind == "Number" and curVal > 50)

in these cases the ovr tag specifies a record as being an override point but also captures whether the override is active.

I think what you are proposing is that curVal maps to the current cmd state, but the ovr tag maps to whether the override is in effect? That seems more like making override metadata versus a real point. And what is the difference b/w curVal in the two points? The ovr version always assumed to be the winner?

If we actually want to trend the override state, then the state of the override needs to be curVal - it the primary "value" of the point right? So based on what I was hearing the model should be:

// cmd point
{point, outside, air, damper, cmd, kind:"Number", curVal:10%}

// ovr point
{point, outside, air, damper, ovr, kind:"Bool", curVal: true | false}

Jason - From being where the rubber hits the road I disagree. I have 8 application engineers working for me at this point. If the group here doesn't formalize the right way to address almost all situations, just inside my own organization I'm going to have 8 different tagging implementations for certain things -- some even for the same end user. If we don't control it here, each implementer is going to have to somehow control it within their own organizations. (On the level of what ESI has done for their own organization -- which takes a good amount of time, effort and will.)

I'll be one of the ones to go too deep, but wanted to voice this opinion.

There is value in knowing the override VALUE and what the AUTO value would have been.

For a boolean output you really have... (hate to confuse this discussion more), but I think you really should know this information if you want your sparks to be actionable and not just noise.

cmd = what the output (relay) is doing ovr = what the override command is auto = what the auto logic is

Normally if a point is overridden, the override point is going to show its in override, and the cmd point is going to show the value of the override as well.

Ex: A point that is in override ON, which the auto logic has commanded on anyway, really isn't that much of a operational issue. Where if the point is in override ON and the auto logic has commanded OFF, it is most defiantly an issue.

Ex: Operator of free cooling cable tower plant, overrides plant into free cooling for 8 hours on a day where the system would have switched to mechanical cooling for several hours. (This is an example of expert operator, doing something good, based upon his judgement). Where if an Operator overrode it the other way (into mechanical cooling when the plant should have been in free cooling mode its a big issue.. $$$)

Dan

Let me add some additional considerations relating to handling overrides in a gateway environment. S4 is planning on implementing Haystack tagging capabilities in our S4 Open Appliances. Today, these products integrate into legacy JCI Metasys N2 systems and publish to either OPC or BACnet. Additional integrations and publishing interfaces are under development so please consider this as a general discussion.

The first product that we developed was the S4 Open: OPC-N2 Router. As the name implies it integrates into N2 networks and publishes to OPC. OPC did not have a standard way of implementing the equivalent to Metasys Override and Release operations. So our approach was to define separate OPC points with the same source string (N2 bus address)but each with an attribute that told us, independently of OPC, what native N2 operation needed to be performed. These include .value, .status, .override, .release, etc. To add tagging in this environment we would need to be able to clearly define the functionality defined by each of these discrete "points" that refer to different operations against the same N2 object.

When we implemented the S4 Open: BACnet-N2 Router many of the above described operations were defined as an intrinsic part of the BACnet protocol so the discrete "points" were not necessary. However, we still allow them to be defined to give the integrator complete control over the condition of the legacy N2 devices.

To generalize, we need to both utilize all of the capabilities of the protocol that we are publishing to while guaranteeing that the features of the legacy system that we are integrating into are available. This drives us to an implementation where we need the flexibility to publish multiple discrete "points" for each physical object in the legacy system. The tagging approach needs to support this situation. That is, the tags need to represent the HVAC functionality of the object as well as the operation that the point will perform against the object (Override, Release, etc.).

I think we should model some set point examples. On an air temperature or flow would an over tag always assume an override to sp?

This is the first big topic from the ESI proposal which I would like to bring to resolution because its an orthogonal concept that covers the entire model.

I believe that the consensus is overwhelming for modeling overrides as separate point rather than making it meta-data on a point itself. This is the first major point to agree upon, if you don't agree and think it needs further discussion please speak up.

If we agree that overrides are separate points in their own right, then the next issue is how to model the tags. Here are some proposals based on current conversation:

1. Define new ovr marker tag which is a new fourth category and is exclusive with the core three point categories of sensor, cmd, and sensor.
2. Define ovr marker tag as addition to sensor, cmd, and sp
3. Define ovr as Ref to the the sensor, cmd, and sp point

For illustration lets consider a scenario for a VFD fan command:

Option 1  dis: "FanCmd" fan cmd unit: "%"
          dis: "FanOvr" fan ovr unit: "%"

Option 2  dis: "FanCmd" fan cmd unit: "%"
          dis: "FanOvr" fan cmd ovr unit: "%"

Option 3  dis: "FanCmd" fan cmd unit: "%"
          dis: "FanOvr" fan ovr:@FanCmd unit: "%"

Same tags could be applied to sensor and sp overrides also.

The problem with option 1 is you don't know exactly what the override is paired with (cmd, sensor, etc?). The most "haystack-ish' way to do it is probably option 2. But as mentioned previously that means that all your queries would need to include not ovr. Then option 3 would more of a pain to setup, but sort of seems more explilcit to me.

Out of all of the options there Brian I do like option 3 and could probably cope with the pain of extra setup. It's nice to be able to link the override point to the actual command point.

However I think we also need to capture the difference between the override value and the actual command value. As per Dan's comments above:

There is value in knowing the override VALUE and 
what the AUTO value would have been.

So I'd like a way to capture this. Building on option 3 I'd like to see something along the lines of:

Option 3  dis: "FanCmd" fan unit:"%" curVal:10% cmd
          dis: "FanOvr" fan unit:"%" ovrVal:20% ovr:"OVERRIDE" ovrRef:@FanCmd

Rather than having the ovr tag as a Marker it could be a String that specifies the level. Valid values could be AUTO, EMERGENCY, OVERRIDE, this will tell us which value the field controller is using.

May have gone a step to far with my example and complicated it too much, but hopefully it illustrates the direction I'm thinking

I agree to option 3 too.

Few questions though... Is this model allows some kind of tagging when override is a matter of priority (like bacnet devices) ?

How can you get the automatic value when overriden ? I mean, if I monitor an output, its value will change if I override it to match the override value... so I will loose what it would have been... If I want this kind of behaviour, I should tag the loop output (?) as the command instead of the physical output...

I am concerned that our discussion is getting beyond reality. Since we are discussing tagging, then we must be sure that the data we are asking for exists in the actual system. When set-points are overridden what does that mean? To me it means that in the process of setting the override a setpoint value is provided and from that point on the value of setpoint will be that fixed value, there will be no other value available.

Further to earlier comments about override being a separate point or metadata. Hind site being 20/20 I would agree with Brian that the metadata approach would be best, with one exception which has come to ligh during this thread, the case where a physical switch is included on the controller hardware that allows a local operator to go to a manual operation. In that case a separate point would be required to detect the position of that switch. There are many products which include such switches, usually at owner request.

How about this idea. I'm drinking some wine right now, so it might not be that good of an idea, but I'll take a shot :}

The only time I think the ovr tag should even be talked about is if you model a 2nd point. IE>.. It's either a 2nd point that is either a software or hardware point. So basically if you just have 1 point, and the user puts that point in manual then you never even need to worry about having a ovr tag. The server software should be smart enough to handle this.

OK, so now if you need to model a separate point to see if it's in a override state, then I say we just add a ovrValueRef or a ovrRef.

There are 2 types of overrides, 1. it's false if it's in auto, and it's true if it's overridden. 2. The value represents what it's override at. IE... 57% if you overode a VFD.

Let's say you have a Supply Fan. So the tags should be fan discharge cmd, and now let's say you want to monitor another physical point that tells you if the fan is in override or not. If this is the case, I say you have another point that has the following tags. fan discharge cmd ovrRef:@122(To the real point).

I would say most of the time, I think we should just use ovrRef, but if the point you are looking at isn't true (override) or false (auto), then I would suggest using ovrValueRef.

I do agree that your query will now need to be fan and cmd and discharge and not ovrRef. That kind of sucks, but that's what you get if you want to have another point :} You also need to know if it's a sensor or sp as well, so you can tell if the point is a physical input or a software point.

Wine can be good sometime :) I like your idea. It's simple and cover most of the situations.

Regarding the query, it's not bad from my point of view to get ovrd in the list of fan cmd... Can explain strange behaviour... Cmd is OFF, Fan is ON,... oh, ok, there's this other point wich is an override and it's ON...

And if there is no secondary point on a controller (ovr variable or switch), you won't have those ovr points in your queries...

I would vote for this... and a glass of Bordeaux...