Optimal start/stop (OSS) is available as an out-of-the-box function in almost every HVAC building automation system sold on the commercial market today. Folks toss the term around with a very loose understanding of what it means. PID controls suffer the same dilemma. When you ask any industry professional to define OSS, you’ll get this generic and common response (Figure 1):
Figure 1. Response on OSS definition. Source: http://hvac-talk.com/vbb/showthread.php?101579-Optimal-Start-Stop
Look at the date (Figure 2) of this post:
Figure 2. Date of OSS definition response. Source: http://hvac-talk.com/vbb/showthread.php?101579-Optimal-Start-Stop
OSS has been around as a concept for a very long time. Here is a link to a 1983 department of commerce publication (typewritten) describing one algorithmic approach. It seems simple enough and, therefore, it gets overlooked all the time. Two calculations that just figure out when to start the equipment and when to stop it based on how it has performed in the past. The engineering community has made it a habit to specify it without giving it any thought, and the controls industry has responded by providing installing contractors several black-box solutions. Why are they black box? Because, generally, controls products do not provide their installing contractors the math behind their OSS algorithm. Of course, there are exceptions to the rule, and if you find yourself seeing the math behind the OSS algorithm you install, then you can consider yourself lucky. I find this problematic because, having been a controls programmer of several different controls products, I’ve found they all behave differently. Sometimes, when they’re haphazardly implemented, they can have the opposite effect of “optimally” starting a piece of equipment and end up running or stopping equipment when it shouldn’t be, which has an energy/bottom line impact on building performance. It’s also been my experience that, because they cause units to start in an unpredictable way, most facilities folks disable it. Predictability is something folks like out of their machines.
Some Examples
Below are some examples of different implementations of OSS from four different controls products of different vintages (Figure 3). One thing they all have in common is that they all look at the outside air temperature (OAT), if the unit is scheduled occupied (OCC), and zone temperature. The rest of the inputs to these four algorithms vary based on each of the four manufacturers’ different interpretations of an OSS algorithm. Some algorithms use the setpoints of the space, some use the next scheduled start time, and others use vague terms like “building cooling factor” or “dynamic parameter adjust.”
Figure 3. OSS implementations from four different controls products.
The important take away from looking at these four very different implementations of a seemingly “industry standard” concept is that there is no standard. You can, rightfully so, assume that all four of these OSS algorithms – if given the exact same space conditions in the exact same building during the exact same weather – will yield different results. So, you might ask, “Which one is the right one? How do you know if your unit has started ‘optimally’? How do you know it stopped ‘optimally’? What is ‘optimal’ anyway?”
The Basics of Optimal Start/Stop
Figure 4. Outdoor weather and building occupancy, setpoint, and temperature over 24 hours without OSS.
When a space goes from unoccupied to occupied, the mechanical equipment has to bring the space temperature to setpoint. The time it takes to do this is called “recovery time” (Figure 5).
Figure 5. The time is takes a building to reach setpoint (recovery time) after the building becomes occupied, without using optimal start.
The principal idea behind implementing OSS is to try and predict what a space’s recovery time will be and shift the scheduled start time of that piece of equipment by the space’s recovery time. The reason this is considered “optimal” is because it takes the guess work out of the schedule and ensures that, by the time the space is occupied by people, it is comfortable (or at setpoint) by starting at exactly the right moment ahead of scheduled start to utilize only the energy that’s needed to bring the space temperature to setpoint.
Conversely, optimal stop uses the same concept but looks at how long it takes a space to drift away from setpoint and stop it ahead of scheduled stop time to allow the temperatures to drift as occupants leave the building. The idea is to stop the units early enough to save some energy and take advantage of the building’s insulation.
Figure 6. Length of optimal start time versus optimal stop time.
You’ll notice in the above example that the optimal stop time will be a lot shorter than the optimal start time (Figure 6). This is usually because office buildings go unoccupied in the afternoon right after the outdoor conditions hit their peak for the day. Occupant comfort is the goal, so we want the building to achieve setpoint right as the building begins to be occupied. This means that the optimal start should begin early enough to allow time for the building to reach setpoint before occupancy. We also want the building to continuing being comfortable until it is unoccupied, meaning that the optimal stop time should be late enough that the building is at setpoint until everyone is gone. Thus, the optimal start time will be much longer than the optimal stop time.
All this seems pretty obvious so far, right? The tricky bits that throw the obvious out the window are:
- Building Environmental factors influencing recovery time (e.g. weather, windows, and sunlight).
- Some, if not most, controls products will cram this calculation into a small, cheap, distributed controller with memory measured in the kilobytes/megabytes. Given issue number 1 above, the algorithm has to be compressed or simplified to fit in memory (i.e. it is simplified or stripped of functionality).
- There is no standard method to achieving the expected end result.
Basic Optimal Start Process
Let’s just look at optimal start. Later, you can think about this process and apply the same concept to drift time and optimal stop. Due to environmental factors being so variable, the immediate thought is to store the amount of recovery time for each day the unit runs along with the environmental factors (like OAT) (Table 1). That might look like this:
Table 1. OAT and Recovery Time for Optimal Start
This means you have data points for 365 days in your controller for the first step. A next step toward predicting recovery time might be to average the recovery time for a group of outside air temperatures. This is because two days might have the same OAT, but different amounts of sunlight or occupant load affecting the space. This is called “binning” on OAT. So, using the above example you can begin to see how you need another data set calculated using the original data. Using this technique, with an outdoor air bin size of 5°F, our data now looks like this (Table 2):
Table 2. Binned OAT and Recovery Time for Optimal Start
This data adds another column to our original data set. Note that, in the cells with a dash, there is no recovery time data because the unit was unoccupied as shown in the first table. Using the table above, you can average recovery time on the OAT bin and determine a single expected recovery time for a given outdoor temperature (Table 3):
Table 3. OAT and Expected Recovery Time for Optimal Start
Now, you can get an idea on how a system can determine when to start given the average historical performance (Figure 7). This algorithm would ideally update everyday given OAT and space conditions.
Figure 7. Optimal start time based on determined recovery time.
Diversity
Given a random sampling of some zone temperature data we have access to, I looked at the time period 15 minutes before and 15 minutes after a transition from unoccupied to occupied across four different spaces, each on different floors of a rather large building in the northeast of Vermont. Analyzing all the transitions from unoccupied to occupied for all outdoor temperatures for 2017, I was able to see how far the temperature had drifted from setpoint (Figure 8). By looking at this data, you see some important considerations for our basic OSS algorithm shown above:
- There is a lot of variation between the spaces.
- There is a correlation between outside air temperature (OAT) on recovery time (but we already knew this).
- There are other factors influencing our data at the extremes of OAT (there is likely a lack of extremes, or a small set of them, in the data set).
Figure 8. OAT impact on space temperature recovery for different building zones.
You can almost make out a wave in the overall pattern because we have less data at the very warm and very cold times of the year.
Figure 9. Pattern in OAT impact on space temperature recovery for different zones.
The green line shows an approximation of how the OAT has impacted each zone over the course of the year (Figure 9). In OSS, each space would be tracking its own recovery time across each outdoor air condition and using that data to predict the optimal start time.
Figure 10. OAT impact on space temperature recovery in Zone 4.
So, looking at Zone 4 in the above graph, you can see that the equipment will want to start earlier in temperatures between 15°F and 25°F. It would also start earlier at temperatures above 65°F (Figure 10). This might be because either we don’t have enough data points under 15°F or because there is some other building influence. A common influence is fin tube radiation, which can be a secondary source of heat not controlled by the space temperature we are examining. It used to be a common practice to have exterior walls be a single zone of fin tube radiation that would just turn on at a certain OAT setpoint and stay on until the OAT crossed back into warmer temperatures. This is no longer a recommended practice, but can be an impact on OSS behavior for better or worse.
Another consideration we need to examine is acceptable dead band in OSS calculations. Dead band is the temperature range around your setpoint in which your equipment does nothing. It is used to prevent under/over reaction of HVAC equipment, which lowers wear and tear and saves energy. In the graph above, a two degree change of space temperature in either direction can be considered close enough to set point where there is no need for optimal start/stop. So, the graph ends up looking like this:
Figure 11. OAT impact on space temperature recovery for Zone 4 only when OSS is needed.
Zone 4, based on the data (which is all a controller will have), will only need an optimal start/stop adjustment during temperatures between 15°F - 25°F and 65°F - 80°F (Figure 11). Let’s look at Zone 1 the same way.
Figure 12. OAT impact on space temperature recovery for Zone 1.
Here is a room on a different floor, on a different side of the building, and with different environmental factors. You can see some variation but, for the most part, OSS would have to make a consistent adjustment at any temperature below 40°F (Figure 12). It would not have to make any adjustments for summer conditions!
If these are variable air volume (VAV) controllers doing the OSS calculation in a standard office building, they might be memory constrained. This is often the case to keep the cost of these ubiquitous controllers low. It is common practice for design engineers to require OSS at the zone level, meaning they are forcing this little cheap controller to examine these factors. This can result in user frustration, as these controllers often do not actually start/stop equipment optimally. Also, there is often no way to check/commission the OSS without a heavy scrutinization of the trend data against assumptions since most manufacturers do not publish their math. Most controls contractors do not provide their programs, so there is no way to determine if the algorithm was configured properly. I’ll give you some red flags/checks to look for. Given everything we’ve talked about here, your OSS should require at a minimum:
- Room temperature
- Room setpoint
- Outdoor air temperature
- Current occupancy command from a schedule
If those points are not available in trend data over the course of a year (at minimum), you won’t be able to properly determine if your system is “optimally starting/stopping” your equipment.
If your system is optimally starting/stopping your equipment, you should see a time delta in the trend data between the occupied command and the unit status. The equipment should be responding to environmental conditions and, if your control system is well programmed, it should indicate to you in an easy to understand graphic that the unit has optimally started and stopped ahead of schedule.
I know this is a lot. You can take a deep breath and relax because if you are unsure of whether or not your OSS is working in your building, feel free to reach out to us. We have the ways and means to look at your data and retrocommission your system rather quickly to determine if OSS is working for you as it was promised. We can also work with your controls contractor to get anything that’s not working fixed up, and find those utility bill savings that OSS should be providing.
