Hey everyone,

The AHU Standing Working Group would like to open a few new proposals for public comment. Please comment if you have any questions, concerns, or input. Thanks!!

Filters

We would like to propose a change to the filter tag. While Haystack 3 specified a few points with the filter tag, we would like to expand it to be used on either an equip or point (very similar to how fan or pump are used now). Under this scheme, the duct section would also be flattened onto the filter equip or point. A few examples:

{return air filter equip}
{outside air filter alarm sensor point}
{discharge air filter delta pressure sensor point}

This would more cleanly integrate filters into the Haystack 4 taxonomy, and allow implementations to order filters within airside systems using the airRef tag.

Min/Max

We would like to propose min and max as optional marker tags on sp points, indicating that a corresponding sensor value is controlled to above or below the sp. For example, {zone air co2 max sp point} would indicate the value at which ventilation is increased to reduce zone air CO2.

Minimum and maximum setpoints would be directly applicable to many indoor air quality limits like humidity, VOCs and particulate matter, as well as being useful in modeling resets.

Thanks Jay for getting this out

For example, {zone air co2 max sp point} would indicate the value at which ventilation is increased to reduce zone air CO2.

I would actually put this one up to debate:

a) you do not use max unless it would be ambiguous or you need to pair it with a min point. For example we could assume that all air quality points are max value without explicitly adding that tag

b) you always use max if its truly a upper limit setpoint

If we go with option b, then we would need to go thru the prototypes and update them accordingly

For the above, I'm in agreement with option b.

Using another example, mixed air temp sp vs. mixed air temp min sp convey two different ideas. The former should refer to an economizer operation and the target setpoint of the mixed air damper operation. The latter would typically be a soft limit that pulls back the damper position (say if a preheat coil failed causing temp drop) to hopefully prevent a freeze condition, regardless of the main control loop.

One thing to keep in mind is the complexity of the filtering. If you use option b then your filter would need to be:

zone and air and co2 and sp and not min

Or

mixed and air and temp and sp and not min

Things get complicated and error prone when you have to start putting "not" in your filters just to get the actual point you want. I would like to see tagging be complete so that the filter is always positive, inclusive and unambiguous.

Option a removes some of the ambiguity.

I think maybe what you are getting at Paul is that if we have a min and max, then we might also need a third tag to make it a complete exclusive choice. Lets say we call it midpoint (not sure about best term). But in that case we could say that all setpoints should define an exclusive choice between min, midpoint, max. While that is a little verbose, it would be unambiguous and would never require a "not" query.

Anything to avoid the need to use "not" in the filter to get the real point. Some implementations I see have multiple points brought in for commissioning purposes or that implementer's unique architecture for control . It takes time to decipher and to exclude these special and custom points and tags in order to get the real point. I have played around with concepts like: actual - the actual sensor physical - the physical sensor io - meaning the physical io sensor

I like physical or io because that maps to mechanical drawings that typically calls out the physical IO points.

A recent example is where I have physical IO points for return air temperature and return air humidity and the BMS calculates a return air dew point. Dew point is a calculated temperature and should have a "temp" and "sensor" tag but now I can not easily distinguish between the actual return temperature and the calculated dew point unless I use "not dewPoint" in the filter.

I have also seen this happen on dampers and valves where the BMS implementer introduces points like min/max damper/valve position where it is not a limiting set point but rather the min/max of the actual damper position for the day/week/month. These points are tagged as "sensors" so in order to get the actual damper/valve position I have to filter for "not min and not max". These min/max day/week/month points also happens on kW points on chillers and VFDs.

I hope this illustrates real world use cases. I would love to see an elegant solution to tagging the real, physical IO points for clean and direct filtering.

Thanks for bringing up this concern, Paul. I agree that the "not" filter situation can be extraordinarily difficult in everyday usage.

I see 2 viable options:

1. Introduce a new tag to denote "ordinary" setpoints. The main problem here is that it will be difficult to match industry nomenclature, where setpoints are typically non-qualified ("discharge air temp setpoint"). So, for this to be successful, I think the tag must be especially intuitive. Some options might be: effective, final, or midpoint.
2. We explicitly require that an "ordinary" setpoint must not be present if an equivalent min or max setpoint is. When you really think about it, an "ordinary" setpoint is simultaneously a min and max setpoint. Adding both those tags to every ordinary setpoint seems untenable, but it does imply that min/max setpoints and ordinary setpoints should not exist side-by-side. If we make this explicit, then it removes the need for not filters. The main problem with this is enforcement.

What are peoples preferences between these two approaches?

I have seen controls implementations where there is one effective set point and then a min and max calculated in the BMS based on a dead band. All three points exist when you query the BMS. We may choose to bring in only the effective set point or only the min and max, however, that does not eliminate the need to uniquely distinguish all three points. Perhaps a term like "singular" for a single original set point.

I think the solution may need to be different between set points and sensors.

My challenges have tended to be more around physical points and calculated derivatives of those points (dew point, day/week/month min and max, etc.) I would like to see a tag that uniquely identifies the original point vs. calculated derivatives.

I like the idea of adding an "io" or "physical" tag for physical IO points.

I would like to echo some of the comments, and add our own experience and usages.

Using a VAV box as an example, and looking at the "zone air temp sp", we frequently see setpoints for both "occupied" and "unoccupied" periods, along with an "effective" setpoint. These are further associated with either "heating" or "cooling".

To avoid having to use "and not", we have added the tag "effective" on the true setpoint(s) that the box is following. In addition, and also not part of the standard, we use "occ" and "unocc" to further identify setpoints.

So, for a give VAV, might have the following "zone air temp sp" points. While we might not use any of these points directly in analytics other than the first two, we have to use the "effective" tag to help unique and avoid the "and not" problem:

zone air temp sp heating effective

zone air temp sp cooling effective

zone air temp sp heating occ

zone air temp sp cooling occ

zone air temp sp heating unocc

zone air temp sp cooling unocc

If all we have is a single setpoint, we might only have this point:

zone air temp sp heating cooling effective

We think the use of "effective" has worked well for us in this context.

Another example that might have to be considered (as an example) is the with an air handler's minimum outside air only damper, and is separate from the main outside air damper (command in this example). To help unique and identify the "minimum" outside air damper, we tag as "minOutside air damper cmd". If we had tagged as "min outside air damper cmd", it would have required an "and not" to unique from the main outside air damper, that would be tagged as "outside air damper cmd". This works, but might not be ideal. I suppose one could create separate equipment for the dampers, and unique that way, but we rarely do so.

Lastly, we frequently see a flow setpoint that is really the "minimum" flow, and varies over time (not just a single value). As an example, we might see this on outside air damper.

First, we would have the standard "outside air flow sp". In addition, we might have a point that is the "min" flow setpoint of outside air. Again, to avoid the "and not" problem, we would tag this "minimum" flow setpoint point as "outside air minFlow sp".

None if these solutions are perfect. My reason for writing here is to give some more examples of usages where we might need to reconsider our current tagging model to avoid the "and not" problem.

Eric

Thanks for your input, guys.

While I'm definitely open to a tag denoting an "ordinary" setpoint, I think it's worth considering that this is a breaking change from both a tag and filter perspective. I regret suggesting effective - that probably muddied the water. We've also heard midpoint, final, and singular, none of which seem especially intuitive or compelling. Are there any other ideas?

I think it's also worth differentiating between min/max setpoints which control a sensor reading to above or below the value, and min/max setpoints that indicate the range of another setpoint (like a reset). Our main focus here is to address the first situation.

The rule that has served us well for many years now is that when you get into a situation where people find themselves using "and not", then it must be fixed in the ontology by adding a new exclusive choice.

I think it's worth considering that this is a breaking change from both a tag and filter perspective

I don't think this is true. You can always add an additional level using a narrowing tag to disambiguate two or more instances that would otherwise have the same markers. For example if you have just one sp point then you can assume its the midpoint. You don't have to force people to tag it that way or change your filters. But if you have more than one, then we would specify that you must quality with an additional choice such as min, max, midpoint, etc.

BTW: we also need to consider the deadband configurations

How comprehensive are you trying to be about setpoints? For analytics I try not to get too complicated. I'm usually looking for the large deviations.

If we are talking about zone set points, I use "effective" all the time. Both for a single, overall effective set point and for effective heating/cooling when there are two. It is hard to duplicate the BMS effective logic in analytics from the heating/cooling/occupied/unoccupied set points and a hvac mode and occupancy point.

On air handlers there can be all kinds of set points: Min/max DAT setpoints for temperature and pressure as well as an "effective" setpoint when there is dynamic DAT temperature/pressure reset.

Some air handlers control to a mixed air temperature setpoint. Some air handlers control to a return air temperature setpoint. Min outside air damper position set point

Economizer enable/disable temperature setpoints Preheat setpoints Humidify/dehumidify set points CO2/VOC setpoints (some times with min/max ranges)

Generally, I have been able to model set points using the standard tags:

effective, heating, cooling, occ, unocc, min, max

for the type of related point.

The only tricky part is zone set points where sometimes you have just one overall effective set point and sometimes you have two heating/cooling effective set points. Currently I use "and not heating and not cooling" to find the single case. This is why I'd like to see something like "single" or "singular" to uniquely identify that case.

Brian makes a good point about dead band. Almost all of these set points have a concept of dead band. I've seen this implemented many different ways: Offset above the setpoint, offset below the setpoint, divided by two and offset above and below the setpoint. I don't know if we should take that into consideration.

Good insight Brian, thanks for the example. And thanks for the usage discussion Paul.

I think it's best that the AHU Working Group discuss these details in our next meeting.

Paul, if you wanted to join that working group, your experience would be super appreciated ;)

After some discussion this week, we'd like to a mid tag to amend the min and max proposal. mid/min/max would be implemented as an exclusive choice on any sp, which would avoid the "not" filter issue. It also allows independent usage of the occ, unocc, and effective tags.

Below is the proposed tag documentation:

• min: When present alongside an sp tag, the associated sensor reading is controlled above this point's value.
• max: When present alongside an sp tag, the associated sensor reading is controlled below this point's value.
• mid: When present alongside an sp tag, the associated sensor reading is controlled to this point's value.

So the following are a few example points:

• {zone air co2 max sp point}
• {zone air humidity min sp point}
• {discharge air temp mid sp point}

Please respond back with any feedback!

I've been following this discussion, I'm not sure it helps but the terminology I've seen before is bidirectional/unidirectional - min and max sp's are unidirectional, what you're calling mid is bidirectional.

I think min/max/mid work fine for set points.

I would challenge your one example of {zone air humidity min sp point}.

The "humidity" tag for setpoint is ambiguous. In dry climates I use a "humidify" tag. In humid climates I use a "dehumidify" tag. I've worked with single systems that both humidify and dehumidify depending on the season. It is important to be able to distinguish between these two humidity controlling setpoints when writing analytic rules. Each humidify/dehumidify setpoint could have a min/max/mid not unlike an air set point. It is not uncommon to have a humidify min/max and a separate dehumidify min/max that act as a dead band for control. In systems that both humidify and dehumidify, it is not common to humidify all the way up to a single max set point or dehumidify all the way down to a single min setpoint. There are usually small dead bands around the upper and lower range.

Echoing Paul Quinn, who said:

"Generally, I have been able to model set points using the standard tags"
  effective, heating, cooling, occ, unocc, min, max

I agree. We have been able to model systems (particularly zones) with either a single sp, or both heating and cooling sp, as follows:

Two Sp Case:

Heating Sp => zone air temp heating sp effective
Cooling Sp =>  zone air temp cooling sp effective

Single Sp Case (With both heating and cooling capabilities)

zone air temp heating cooling sp effective

Single Sp Case (With only cooling capabilities)

zone air temp cooling sp effective

This tagging allows for the other setpoints we might find that are not the primary setpoints we would use in rules, etc, without resorting to the "and not" filter. These points we frequently see are:

zone air temp cooling occ sp
zone air temp cooling unocc sp
zone air temp heating occ sp
zone air temp heating unocc sp

Regarding Jay's proposal, I have two questions/concerns:

1) Does it address the problem of effective setpoints, as I have outlined above? Wouldn't we still need a way to identify those "effective" setpoints, regardless of if they are min or max or midpoint, without "and not"?

2) Isn't a heating sp, for example, a max sp by definition? Does adding max to a heating sp add anything?

I am glad we are really diving into this before we introduce changes that we all will have enbrace, especially with regards to zone equipment, which is one of the most used equipment types, in our experience. Thanks everyone for chiming in.

Good questions and discussion @Eric Loew. Thanks for your input!

1) Does it address the problem of effective setpoints, as I have outlined above?

No. But the goal of this proposal was to generalize min and max setpoints, not resolve the usage of effective.

Wouldn't we still need a way to identify those "effective" setpoints, regardless of if they are min or max or midpoint, without "and not"?

No more than before. The effective usage examples that you and Paul have given appear to match the descriptions in the Zone documentation. It is probably worth a separate proposal to more completely define effective, generalize it beyond zone air temp situations, and consider the "not" effect.

2) Isn't a heating sp, for example, a max sp by definition?

Yes, definitely (although I think a heating setpoint is actually a min)

Does adding max to a heating sp add anything?

No. However, the min / max tags allows us to generalize to setpoints that aren't directly related to cooling or heating (like CO2, humidity, etc).

---

This raises a good question on whether we replace heating / cooling with min / max, use them alongside one another, or keep using heating / cooling. For example, would zone air temp heating sp become:

1. zone air temp **min** sp
2. zone air temp **heating min** sp
3. Stay zone air temp **heating** sp

Personally, I lean toward option 2 for backwards compatibility and conformance to the proposed min-sp defintion, but it's definitely open for discussion!

In my opinion min & max should not be used in place of heating and cooling, but used with them only when necessary to provide additional clarification.

This may not apply as much to the final effective setpoints, but more to the setpoints that are used as parameters for calculating the final setpoint. Many of these points are rarely utilized in analytics, but as Haystack makes its way to being implemented at the control level this type of point will need to be modeled as well (and likely require some additional tags).

Some examples:

• Zone temperature heating and cooling user adjustment limits such as max occupied zone heating setpoint and minimum occupied zone heating setpoint.
• Discharge air temperature reset limits based on heating or cooling mode.

I feel these examples show that heating and min could not be used interchangeably without adversely limiting ways to identify points.