Demystifying Modern Optimal Start Algorithms for HVAC Systems

This article explores the evolution of optimal start and stop strategies for HVAC systems, focusing on the latest innovation: an adaptive tuning algorithm developed in a PNNL-authored paper. This algorithm dynamically calculates the optimal start time to efficiently warm or cool zones in large-scale HVAC systems.

This topic has consistently captured my interest: the optimal start and stop of HVAC systems. It’s a challenge I’ve faced firsthand during my years as a BAS technician, particularly in cold-weather climates like the upper Midwest USA, where winter overnight temperatures often plunge below zero degrees Fahrenheit. A common question arises: how long does HVAC equipment need to run to adequately warm a school before occupancy?

In extreme conditions—whether freezing winters or hot, humid summers—where energy consumption is at its peak, opportunities for optimization abound. From my experience in cold weather, optimal start strategies often lead to HVAC equipment running for hours before a building’s actual occupancy. This can result in significant energy waste, especially when HVAC systems condition outdoor air for ventilation purposes during the warm-up period—long before anyone has even arrived in the building.

Despite decades of attention, this issue remains only partially resolved. Even the most recent PNNL paper concludes that there is still considerable room for improvement, especially for scenarios involving extended periods of unoccupied time. For example, Monday mornings, following a weekend of unoccupied temperature resets, may require a different approach than other weekdays.

It’s fascinating that, despite its long history, this topic continues to offer opportunities for innovation. In this article, we’ll explore how the industry has progressed and take a closer look at PNNL’s latest adaptive tuning algorithm to understand its advancements and potential for addressing these challenges.

Rewind the clock over 50 years to the post-WWII era, when homes in the upper Midwest USA commonly featured coal chutes as a standard practice for heating. During this time, large HVAC systems were predominantly controlled using analog equipment. For instance, the panel shown below likely represents an air handling unit control system. It utilized proportional-only devices, which relied on analog temperature sensors to proportionally adjust valve or damper positions. These systems, while innovative for their time, were relatively simple compared to the advanced digital controls we use today.

If you take a closer look at the picture above, you’ll notice a device resembling the one shown below—a pneumatic relay. These relays operated using air pressure to start or stop a fan motor. Long before the advent of VFDs or soft starters, mechanical time clocks controlled the pneumatic system's day and night air pressures.

This setup allowed the relay to start the fan at a designated day pressure and turn it off at a night pressure. The same concept of day and night pressure was often extended to pneumatic zone controls, where radiant valves or other heating devices adjusted space air temperatures based on the transition between day and night air pressures. These systems provided a rudimentary but effective way to implement temperature control and scheduling in the era of purely mechanical and pneumatic HVAC controls.

HVAC controls remained largely unchanged until the mid-1980s, when direct digital control (DDC) systems began to gain traction. From my research nerding out on Wikipedia, the chemical industry was an early adopter of digital control technology as far back as the late 1950s. However, it wasn't until the 1970s, with the advent of cheaper computer components, that digital controls began to see broader adoption across industries.

The first-generation 1980s DDC systems marked a significant leap forward for HVAC controls. These systems allowed equipment to be started via computerized scheduling, replacing the mechanical time clocks and pneumatic air pressure systems that had been standard for decades. While rudimentary compared to modern solutions, these early DDC systems laid the foundation for the sophisticated building automation systems we use today.

My career in the controls field started much later in the earlier 2000's, during a time when I was often tasked with removing these early, first-generation 1980s DDC systems and replacing them with more modernized solutions, often utilizing the BACnet protocol.

I still recall a conversation with a school maintenance professional who was amazed when that first-generation DDC system was installed. He was astonished at how all the equipment started precisely at the same time—a stark contrast to the inconsistent starts of the old pneumatic systems. Was it optimized for energy reduction or tailored for cold-climate building warmups? Absolutely not. However, it was a significant leap forward simply to have all the equipment reliably starting together, thanks to computerized time clocks and the early scheduling features of building automation systems.

Fast forward some time...

Some of the early adopters of digital HVAC controls likely developed their own DIY optimal start calculation processes, though these methods were probably not studied in great depth or standardized. My experience with optimal start primarily involved the Tridium optimal start block called BOptimizedStartStop, a feature included in the kitEnergy widget of the Workbench tool. This block was designed to calculate the lead time needed to start HVAC equipment before a building’s scheduled occupancy. It relied on two critical inputs: the current space air temperature and the building’s automation schedule, which indicated the next occupancy time. Using these inputs, the block calculated the optimal start time.

The block's calculations were based on a parameter known as degrees per hour, which represented how quickly the HVAC system could heat or cool the space. This parameter, combined with the desired comfort range for the space temperature, allowed the block to estimate how many minutes of runtime would be necessary to reach the target conditions. To prevent excessive energy consumption, the block also featured a not-to-exceed time setting, typically defaulted to 2 hours. This ensured that the system would not start too far in advance of the scheduled occupancy, balancing energy efficiency with occupant comfort.

Despite its straightforward logic, the block faced significant challenges in real-world applications. It relied heavily on static parameters like degrees per hour, which required manual tuning and could not dynamically adjust to changing conditions such as fluctuating outdoor temperatures or varying thermal loads. Field technicians had to spend considerable time configuring these parameters, often through trial and error, to achieve acceptable results. Even then, the block’s performance was inconsistent, particularly in cold climates where it sometimes underestimated the required lead time, leaving spaces uncomfortably cold during occupancy. Additionally, the rigid not-to-exceed time setting limited its adaptability for buildings with unique thermal characteristics or unpredictable weather conditions. While the block represented an important advancement in digitizing HVAC controls, its limitations underscored the need for more adaptive and intelligent algorithms capable of handling real-world variability with minimal manual intervention.

JAR Files

Any Tridium programmer is familiar with JAR files, as they are a central component of the platform. These files contain compiled Java code and are often updated using the Workbench tool to extend or modify system functionality. The BOptimizedStartStop class, found within such a JAR file, is a prime example. This roughly 700-line Java implementation is designed to compute an optimal start and stop process for HVAC systems, albeit with only partial adaptiveness.

What's particularly fascinating is how accessible these JAR files are. Anyone can simply decompile them to examine the underlying code and understand how specific processes, like optimal start, are handled. In the case of BOptimizedStartStop, the algorithm includes mechanisms to adjust parameters such as runtimePerDegreeHeating and runtimePerDegreeCooling, which play a critical role in determining lead times. However, the adaptiveness is limited to retrospective adjustments based on past performance, making it far from a fully dynamic or predictive solution. The flexibility to examine, modify, or even replace this kind of functionality highlights the versatility of Tridium's platform and its potential for customization, even if the out-of-the-box implementation falls short in certain scenarios.

Go to a website like this and peak inside! https://www.decompiler.com/jar/1fbbc96af3dd4a91a6a2756998a2661f/BOptimizedStartStop.java

I would assume this code is a good 20+ years old, and perhaps something Tridium, at large, could consider updating to something more modernized. If there are any Tridium developers out there, this could be a great project to bring modernized optimal start and stop features to BAS, moving beyond strategies that are two decades old. I’d also be willing to bet that AI could easily ingest the PNNL paper and update this existing 20-year-old Java code to create something far more modernized and adaptive with minimal effort.

PNNL Paper Model Three

The white paper, which can be downloaded from here, is another excellent piece of research and writing by Srinivas and his team. The core of the paper highlights that "existing optimal start methods are based on research that is several decades old" and advocates for data-driven methods as the way forward. These methods are presented as being more "lightweight" compared to physics-based models or model predictive control (MPC) strategies. Physics-based models, while theoretically sound, can be inaccurate, time-consuming to set up, and require advanced skill sets for deployment.

The paper also emphasizes that physics-based models are typically not adaptive to changes in the building, weather patterns, or occupancy over time. In contrast, a lightweight, adaptive tuning strategy is not only easier to deploy but also more computationally efficient. This adaptiveness allows the system to adjust dynamically to real-world variations, making it a more practical and scalable solution for modern HVAC optimization challenges.

The paper outlines four modeling strategies for data-driven adaptive tuning techniques, with the evaluation concluding that Model Three demonstrates slightly superior accuracy compared to the others. Delving into Model 3, the core of its effectiveness lies in its mathematical framework, which incorporates three key parameters. These parameters are dynamically tuned using historical data each time the algorithm runs, enabling the model to adapt to changing conditions such as building thermal behavior, outdoor temperature variations, and occupancy patterns.

The boiled-down math equation provided in the white paper shown below captures the relationship between these parameters and the optimal start time. By updating the parameters based on observed performance, Model 3 achieves a balance between computational simplicity and accuracy, ensuring that the system starts at the optimal time to maintain comfort while minimizing energy consumption. This adaptive mechanism is central to its performance and highlights why it outperforms the other models in the study.

The first parameter, denoted as alpha_3a, represents the time in minutes per °F required to change the indoor temperature by 1 degree. The second parameter, alpha_3b, also measured in minutes per °F, indicates the time interval needed for the indoor air temperature to shift by 1 degree. The third parameter, alpha_3d, is an adjustment factor, measured in minutes, that accounts for the difference between the indoor temperature and the setpoint when data is captured. All three parameters are dynamically tuned based on historical data to improve the model's accuracy and adaptability. My best interpretation in a Python function would be like this below, where a data structure contains previous records in minutes of the past optimal starts, including the zone air temperature setpoint, zone air temperature, and outside air temperature, to output a t_opt value.

def calculate_optimal_start(current_conditions, alpha_3a, alpha_3b, alpha_3d):
    """Calculate optimal start time based on Model 3."""
    T_sp = current_conditions["occupied_set_point"]
    T_z = current_conditions["zone_temp"]
    T_o = current_conditions["outdoor_temp"]

    t_opt = (
        alpha_3a * (T_sp - T_z)
        + alpha_3b * (T_sp - T_z) * (T_sp - T_o) / alpha_3b
        + alpha_3d
    )

    return t_opt
        

I can then compute the required minutes with something like the example below, where a data structure contains the 4 or 5 AM zone air temperature values, outside air temperature, and previous records detailing how long it took to warm up the zones in minutes during past attempts. This approach seems conceptually similar to an iterative brute-force method for calculating linear regression. However, the key difference here is that this is not a linear problem. The mathematical framework developed by Srinivas and his team embeds all the non-linear properties of heat transfer and thermal dynamics to output an optimal start time in minutes.

What I’m still trying to figure out is how to set an optimal learning rate for the model. The learning rate determines how quickly or smoothly the algorithm converges to retrieve the optimized value. Without a proper learning rate, the model might overshoot, converge too slowly, or fail to stabilize entirely. Understanding and fine-tuning this parameter is essential for achieving accurate and reliable results. The white paper also notes that a minimum of 7 days of data is required to begin iterating and tuning the alpha_3a, alpha_3b, and alpha_3d variables. This initial data serves as a baseline to estimate the system's performance and allows the algorithm to start adapting and refining these parameters over time. With this historical data, the iterative process can begin, ensuring that the model accurately captures the building's thermal dynamics and optimally predicts the required start times.

Feel free to reach out or leave a comment if you notice anything incorrect or if you’re interested in trying out this Model Three approach in pseudocode! I’d be happy to collaborate or provide additional details.

# Configuration Parameters
learning_rate= 0.1  # What is an optimal learning rate???

# Initialize Parameters
alpha_3a = 10  # Default time to change indoor temp by 1 degree
alpha_3b = 5  # Time interval for outdoor temp influence
alpha_3d = 0  # Dynamic adjustment for start time

# Historical data with sensor values recorded at 4 AM
historical_data = [
    {"zone_temp": 50, "outdoor_temp": 10, "warmup_time_minutes_history": 120},
    {"zone_temp": 48, "outdoor_temp": 12, "warmup_time_minutes_history": 115},
    {"zone_temp": 52, "outdoor_temp": 8, "warmup_time_minutes_history": 125},
    {"zone_temp": 50, "outdoor_temp": 11, "warmup_time_minutes_history": 118},
    {"zone_temp": 51, "outdoor_temp": 9, "warmup_time_minutes_history": 122},
    {"zone_temp": 49, "outdoor_temp": 13, "warmup_time_minutes_history": 110},
    {"zone_temp": 47, "outdoor_temp": 14, "warmup_time_minutes_history": 108},
]

# 4AM Conditions Check
current_conditions = {
    "zone_temp": 48,  # Current indoor temperature
    "outdoor_temp": 12,  # Current outdoor temperature
    "occupied_set_point": 70,  # Occupied temperature setpoint
}


def compute_minutes(alpha, alpha_new, learning_rate):
    return alpha + learning_rate * (alpha_new - alpha)        

Without delving too deeply into the details, I believe these algorithms function as a brute-force, iterative approach that optimizes based on error and historical data. While they share similarities with machine learning concepts, they are much simpler in design. The process resembles gradient descent but is even more straightforward in its implementation.

For example, linear regression is typically calculated using Ordinary Least Squares (OLS) methods, which provide a direct mathematical solution. However, linear regression can also be solved iteratively using a gradient descent approach, where the algorithm adjusts parameters step by step to minimize error. This iterative method arrives at the same conclusions as OLS by repeatedly optimizing for error and updating the weights or tuning parameters with each iteration.

I think these PNNL-type algorithms can be viewed through a similar lens. They operate as tuning algorithms that incrementally adjust weights or parameters over time, optimizing performance by reducing error little by little as more data becomes available. This makes them adaptive and effective for scenarios where real-time or historical data drives the control process.

I have a full implementation of this simulation in Python here, where I am experimenting with different HVAC optimization strategies in pseudocode. While I am still exploring and testing this approach, the implementation serves as a functional framework for further development. I remain hopeful that PNNL will eventually release the code they used to generate the results in their research paper. Access to their official implementation would not only help validate my efforts but also provide deeper insights into how their algorithms were constructed and fine-tuned to achieve their reported outcomes.

If the building operates as more than just a computerized digital time clock

An adaptive tuning strategy will always retain some similarities to older, non-adaptive strategies, as the fundamental principles of preconditioning a building remain the same. Whether implemented in a BAS or an IoT platform, the code must start with a clear understanding of the building's occupancy status. For example, if the building is unoccupied—such as during the middle of the night in the dead of a cold January—it's critical to determine whether the following day is a weekend, a holiday, or an occupied workday.

If it is an actual occupied building day, there needs to be a window of time to assess the building's conditions and gather key data, such as the indoor space air temperature and outdoor air temperature. These inputs are essential for models like Model Three, which rely on these parameters to compute the minutes required to optimally warm up the space.

Generally speaking, outdoor air temperatures tend to remain stable during the early morning hours, such as between 4 AM and 5 AM. This period provides a reliable window to evaluate whether zones require significant preconditioning, especially for buildings that may take up to two hours to bring all zones up to setpoint. By using this early morning data, the system can make more accurate predictions and ensure that the building is preconditioned efficiently, without wasting energy or compromising occupant comfort.

If we gather data during the 4 AM to 5 AM window, we can calculate the minutes required to warm the building optimally. The HVAC system would then remain idle until this calculated optimal time to start up. This approach applies to various systems—whether it’s an air handling unit (AHU) serving multiple zones, a single-zone AHU, or even a set of heat pumps covering a wing of a school. The key is having a thermally representative zone, where the zone air temperature can be averaged or used directly as a single input for the algorithm. The system type matters less, as long as the zone air temperature data is reliable and representative.

The core of the algorithm involves waiting until the optimal start time, measured in minutes, becomes less than or equal to the time remaining before the building is occupied. At that point, the HVAC system would start, initiating commands to the BAS to run the equipment in a recirculating air mode. During this recirculating mode, the algorithm continuously monitors the zone air temperature. Once the zone reaches the occupied air temperature setpoint, the algorithm records the time delta in minutes. This recorded time delta is then used to tune the algorithm further, refining its accuracy for future warm-up calculations. This iterative process ensures the system adapts to building-specific dynamics and continuously improves its efficiency.

What I am really hoping to see is algorithms like this and compare them to the rule-based, non-adaptive algorithms for optimally starting HVAC!

Using analytics and the power of IoT

One thing we have seen so far is there needs to be historical data retrieved. How can we do that to grab previous days of the 4 AM outside air temperature, zone air temperature, and previous minutes to warm up the zones?

One thing about modern IoT platforms compared to traditional BAS systems is their inherent ability to retrieve data from a database with ease. During my time working with BAS, we rarely, if ever, retrieved historical data directly from a BAS. For example, in my experience with the kitEnergy blocks in Niagara Workbench, we typically worked with live values only. This highlights a potential feature for future BAS platforms—an integrated and seamless capability to gather and utilize historical data from a database. This would significantly enhance analysis, optimization, and adaptability for BAS systems, bringing them closer to the functionality modern IoT platforms offer.

I can quite easily put together some analysis code in Python to compute the minutes it takes for a zone to come up to temperature. This style of coding often involves using basic statistics and creating a variety of plots to identify trends in the data. It’s a completely different approach compared to the type of coding that a developer or software engineer would use to implement an algorithm in an IoT platform. While analysis code focuses on understanding and interpreting the data, implementation code is more structured, efficient, and optimized for deployment and scalability within a production environment. Both styles are crucial, but they serve distinctly different purposes in the workflow.

At a minimum of 7 days we need to come up with something like this:

historical_data = [
    {
        "zone_temp": 50,                // Zone air temperature at 4 AM
        "outdoor_temp": 10,            // Outside air temperature at 4 AM
        "warmup_time_minutes_history": 120  // Minutes it took to warm up the zone
    },
    {
        "zone_temp": 48,
        "outdoor_temp": 12,
        "warmup_time_minutes_history": 115
    },
}        

This data below is actual real data from a temperature sensor during a cold snap in the coldest weather January can throw at Wisconsin, from a building in the upper Midwest USA. I used an analytical approach to retrieve historical records in an attempt to build that actual data structure. Each of the RED dots represents my analytical code, which is just rule-based logic configured to look for sharp rises in temperatures during particular hours of the day when a building is occupied. I then took a simple time delta calculation to determine the minutes required to warm up the zone.

What you can see in the data is that the zone air temperatures for unoccupied and occupied conditions are approximately 64°F and 74°F, respectively. I also found that I needed a lot of visualization techniques to verify I was getting accurate minute data.

You can also visualize this data using a histogram and see those space air temperature values between 64°F and 74°F.

Using my analytical approach, you can calculate the occupied zone air temperature and the building's occupied temperature setpoints for each day in the dataset. This involves computing the daily minimum and maximum space temperature values, which I believe will be particularly effective during extreme weather conditions—whether hot or cold. Such conditions can cause temperature sensors to fluctuate significantly, especially when the mechanical system is not operational. A function in Python will look like this:

def calculate_daily_setpoints(data, exclude_daytypes):
    """
    Calculate daily occupied and unoccupied thresholds for each day.
    """
    daily_stats = data.resample("D").agg({"SpaceTemp": ["min", "max", "mean"]})
    daily_stats.columns = ["min", "max", "mean"]

    thresholds = daily_stats[
        ~daily_stats.index.day_name().isin(exclude_daytypes)
    ].copy()
    thresholds["occupied_threshold"] = thresholds["max"]
    thresholds["unoccupied_threshold"] = thresholds["min"]
    return thresholds        

And when viewing lots of data even when setpoints are adjusting on the control system it appears to work okay.

By computing additional statistics, we can observe trends in the data, including the time it generally takes to warm up zones. The green dots below represent the unoccupied space air temperature maintained by the control system at 64°F. The red dots indicate the outdoor air temperature at 4 AM, while the bar chart displays the calculated minute-level values derived using my rule-based analytical approach.

This blog post might be getting a bit long-winded, but what stands out to me is the inconsistency in warm-up times. If the warm-up times were consistent, the bar chart values would all align, right? So, if we are starting from a steady 64°F unoccupied temperature, what factors are driving the variability in the calculations? Could it be changes in outdoor air temperature, system performance, or differences in zone-specific conditions? This inconsistency raises questions worth exploring further. So lets make some more charts and see if there is any relationships in the data.

This chart below also incorporates the hot water system temperature, as I was curious to see if the temperature of the hot water boiler system impacts how long it takes for a zone temperature to warm up. Does it? Typically, HVAC systems are designed or sized based on worst-case scenarios. For example, a VAV box zone coil is usually sized for a boiler water temperature of 180°F. If the boiler water temperature is lower than this, there can be performance degradation in heat transfer. This raises the question: would attempts to lower the boiler water temperature result in longer warm-up times?

If you plot the data in a relationship matrix, as shown below, across an entire winter using a temperature sensor value—such as one that could be used to train an adaptive tuning optimal start algorithm—you can observe slight differences related to the Monday morning warm-up issue. This is an area where research, as noted in the conclusion of a referenced white paper, has yet to fully address the extra time required to warm up buildings on Mondays.

In the lower left-hand corner, there appear to be some subtle relationships between the 4 AM boiler hot water supply temperature values and my calculated warm-up times. The plot to the right of that shows the expected linear reset behavior of the boiler system, where the controls adjust the water temperature towards the design point of 180°F as the outside air temperature drops. However, does this warmer hot water supply temperature lead to better performance by reducing equipment runtime during warm-up? This is worth considering, as it also takes fan system electrical energy to distribute the heated air in the VAV AHU system.

Another interesting application for analytics could be determining how quickly zones lose heat during winter. This could help identify poorly insulated zones and potentially exclude them from aggregation or averaging calculations. Zones with thermal issues, when compared to others, could hinder effective optimization strategies, making it important to account for such discrepancies.

Conclusion

This month's blog post may be a bit long-winded, but it delves into a fascinating topic—one that I still have much to learn about, especially the mathematics behind tuning algorithms. With summer still a few months away, I haven’t yet explored that data, but being located in a very cold winter region of the world makes this topic personally compelling. What’s particularly intriguing is that the industry has yet to fully master this concept, even in research!

How many buildings today are actually implementing optimal start, and is it truly achieving optimal results? Or are modern buildings essentially functioning like 1960s VAV AHUs on mechanical time clocks? I suspect that many buildings still operate in this traditional fashion because it’s simple, it works, and there’s little incentive for maintenance personnel to prioritize energy savings. After all, why would a maintenance technician care? Their performance is often measured by how quickly they resolve temperature complaints, not by how much energy the organization saves. Besides, the accounting department handles the utility bills....! That's the simple truth!

That said, I’d love to hear your thoughts on this. I also hope that researchers in this field can develop easy-to-follow pseudocode to explain the underlying theories. This would allow application developers to implement the concepts on their preferred platforms. Too often, research ends up buried in overly complex IoT platforms, making it inaccessible. I wish the reverse were true—start with clear, simple pseudocode that teaches the theory, and let the implementation follow! Until next time thank you for reading!