Learn about NexusCon!
Let’s pick up where we left off last month. In part one, we talked about the problems with traditional supervisory control and how it can be improved. Not much was cutting edge, per se. Advanced supervisory control (ASC) 1.0 is all about doing the simple things well—like setpoints, sequences, and schedules. ASC 1.0 can help optimize and standardize the three S’s and drive huge savings. If you haven’t read part one yet, you’ll probably want to do so before proceeding here.
Now let’s turn our attention to ideas that are a little more cutting edge. Here’s where we’re headed with this deep dive:
Next time, the final installment in this series will be my thoughts on a strategic approach to ASC.
First, a disclaimer. I haven’t yet seen all of these products successfully deployed and operated in real buildings. For now, I can only summarize and speculate on what I’ve heard through Nexus readers, marketing materials, and research papers. I don’t intend to get into the weeds either—just enough nerdiness for you to get the gist and orient yourself in a changing marketplace.
A good place to start is Automated System Optimization (ASO), a term coined by Lawrence Berkeley National Lab (LBNL) as part of their work with the Smart Energy Analytics Campaign:
Automated System Optimization (ASO) tools are a subset of Energy Management Information Systems (EMIS) focused on continuous controls optimization. ASO tools dynamically modify building automation system control settings to optimize HVAC system energy usage while maintaining occupant comfort. Two-way communication with the BAS is the distinguishing feature of ASO solutions. These tools both read data from the BAS and write analytically based optimal setpoints back to the BAS, based on data such as measured indoor, outdoor, and energy price conditions.
I think of these algorithms as an upgrade to supervisory control sequences via intelligently and automatically overriding setpoints. Historically, they’ve focused on HVAC only. And within HVAC, they’ve targeted only a few setpoints per solution. Early pioneers like BuildingIQ focus on the air side by overriding space temperature setpoints and air handling unit static pressure setpoints. On the water side, chilled water plant optimization controllers like those from Optimum Energy or Conserve IT or Automated Logic or Siemens, focus only on setpoints like the chilled water temperature or condenser water temperature.
These original algorithms optimized sequences using techniques similar to traditional trim-and-respond sequences, but they came from the overlay instead of the BAS. Newer players like Kinetic Buildings, Verdigris, Honeywell’s Forge Energy Optimization, BrainBox AI, Smart Locus, and Yardi are targeting all HVAC sequences in one overlay package.
These products attempt to modulate HVAC systems and ramp equipment down as much as possible at any given time. There’s always going to be a limit where further modulation will result in a failure to meet the system-of-system’s requirements. ASO algorithms attempt to keep systems at exactly that limit as much of the time as possible.
Finding this optimal setpoint is a great application for machine learning. The goals of building control often conflict with each other, especially as more and more systems are integrated together. Finding the optimal setpoints, given all of the known tradeoffs, is nothing but a big hairy math problem. Humans could do this math, but it would take too long. And by the time they finish, the results would be out of date.
In the future, the math problems are only going to get hairier. First, consider the changes happening to the electric grid:
Next, consider the evolving demands of building occupants and operators:
Tomorrow’s overlay solutions will expand far beyond temperature and humidity control sequences to address these multiple conflicting demands and growing expectations in intelligent ways. Based on my research, here’s my best crack at summarizing and generalizing them:
As with all new technology, there are early adopters and there are skeptics. I’ve talked to leaders in both camps and heard three main arguments against advanced supervisory control solutions. Let’s attempt to summarize the skeptics.
The first argument is that supervisory control 1.0 works just fine. If a building’s setpoints, sequences, and schedules are optimized, that would capture 80% of the potential energy savings. No overlay needed. And if you need an overlay, it would be something like FDD to help keep the optimized supervisory settings in place. Any new technology added to an optimized stack would see diminishing returns. When ASC upstarts claim these algorithms save 15-20%, the skeptics wonder how much of those savings would have been realized with a simple and traditional control sequence.
The second argument is that most buildings are nowhere near ready for this technology. Their control systems and other building systems are not ready for two-way communication. Their building operators are not ready to stop actively operating. Their systems are not in the physical shape needed to allow true automation. Buildings, just like humans, have what one reader called a “hierarchy of needs”, of which ASC is the pinnacle need. Here’s my quick attempt at capturing the hierarchy:
They need basic needs fulfilled before pursuing the pinnacle makes sense. So when ASC vendors claim their solution “self-installs” or is “as easy to set up as an LED light bulb” or they’re “not looking to get involved in change management”, skeptics are thinking, “this isn’t going to work”.
The third argument is that controlling buildings from the cloud won’t work. Skeptics say the connections aren’t reliable enough. When the connection drops, ASO technologies are forced to relinquish control back to the underlying controllers. If you're depending on this type of control to capture energy and demand savings, they’re only going to be as good as (1) the underlying/original control sequence and (2) the connection to the cloud. ¹
The US General Services Administration (GSA) did a pilot project with BuildingIQ a few years ago that certainly backs up the three arguments above. Here’s a summary:
I would also like to add a fourth piece of skepticism to the hat. I predict the un-explainability of new and fancy ASC control sequences to be a significant obstacle. One pilot project I’m working on right now includes a control sequence modification called “intra-day adjustments to the air handler speed” based on whole building occupancy. When I asked the vendor how this sequence will work without starving some occupied zones of the necessary static pressure to keep them minimally ventilated, they were unable to answer. Apparently that’s the AI’s job.
I have at least one foot firmly rooted in the skeptics’ camp. I’m also quite bullish on these new technologies. How can that be? Let’s continue.
Despite my skepticism and agreement with those of you who have brilliantly poked holes in the value proposition for ASC, I don’t think you should ignore these solutions. Quite the opposite—I think we need them and we need you to play a role in implementing them strategically. Let’s zero in on the first two skeptic arguments: diminishing returns and the hierarchy of needs problem.
For me, this argument evaporates when I think about the hundreds of buildings I’ve walked, audited, or retro-commissioned. In very few of those was supervisory control working just fine. Quite the opposite—the existing supervisory control paradigm is broken. It simply doesn’t work in practice. That’s why there are still such huge opportunities for overlay solutions like FDD and MBCx—solutions that have barely scratched the surface of their potential.
If we agree on that, then the question is what to do about it. The old answer was to put FDD in, identify the faulty sequence or setpoint or schedule, then pay the incumbent BAS vendor to do it right. In my experience, that’s very expensive. And often the fix is just as bad. The list of faults piles up while everyone bangs their head against the wall. With ASC, the new answer could be: put an overlay on top of the BAS with all the optimization algorithms and setpoint standards built-in. With a standardized data model, those built-in algorithms and standards can be scalable and portable to every building in the portfolio (and the next portfolio).
One thing to consider here is whether the Overlay 1.0 business model stands in the way of the acceptance of ASC. If the value proposition of FDD or MBCx depends on claiming 80% of the potential savings, then ASC is going to feel like a threat to providers of those solutions and they might write it off as “diminishing returns”. It’s encroaching on their quick-payback-with-optimization turf and providing another option. Food for thought.
When you look at the pyramid, you’ll see everything beyond the first level depends on and interacts with the control system(s). I think the hierarchy of needs argument falls short because it views each building block of the pyramid as separate from everything else. It ends up looking like this:
This mindset creates more and more silos. Our industry doesn’t need more silos. Open data, RCx, MBCx, FDD, and even ASC are all completely dependent on the performance of the underlying BAS. When they’re viewed separately, there’s a lack of accountability for the actual performance of the building. It’s always someone else’s problem. We often hear, “you touch it, you own it.” Well, who actually owns it?
As more and more systems are integrated together, we need to let our habit of silo-creating fall by the wayside and start thinking about the building as one system. Controls and the optimization of the controls are really two sides of the same coin. With that mindset shift, the hierarchy mental model evaporates.
Suddenly an ASC strategy could be a part of every smart building strategy. For example, when you’re opening up the data in the building, it could be done in a way that allows two-way communication. We set the industry back further when the integration is done in a way that only allows a one-way pull of data. Once the data is opened up, RCx and MBCx and FDD are going to uncover supervisory control issues. With ASC in mind, issues could be fixed in the most efficient or sustainable way. Or fixed automatically.
In the next and final installment, we’ll pull all of this together. How might building owners approach ASC strategically?
¹ Not all solutions in this space need a cloud connection. Chilled water plant optimization controllers/servers are designed to operate locally.
Let’s pick up where we left off last month. In part one, we talked about the problems with traditional supervisory control and how it can be improved. Not much was cutting edge, per se. Advanced supervisory control (ASC) 1.0 is all about doing the simple things well—like setpoints, sequences, and schedules. ASC 1.0 can help optimize and standardize the three S’s and drive huge savings. If you haven’t read part one yet, you’ll probably want to do so before proceeding here.
Now let’s turn our attention to ideas that are a little more cutting edge. Here’s where we’re headed with this deep dive:
Next time, the final installment in this series will be my thoughts on a strategic approach to ASC.
First, a disclaimer. I haven’t yet seen all of these products successfully deployed and operated in real buildings. For now, I can only summarize and speculate on what I’ve heard through Nexus readers, marketing materials, and research papers. I don’t intend to get into the weeds either—just enough nerdiness for you to get the gist and orient yourself in a changing marketplace.
A good place to start is Automated System Optimization (ASO), a term coined by Lawrence Berkeley National Lab (LBNL) as part of their work with the Smart Energy Analytics Campaign:
Automated System Optimization (ASO) tools are a subset of Energy Management Information Systems (EMIS) focused on continuous controls optimization. ASO tools dynamically modify building automation system control settings to optimize HVAC system energy usage while maintaining occupant comfort. Two-way communication with the BAS is the distinguishing feature of ASO solutions. These tools both read data from the BAS and write analytically based optimal setpoints back to the BAS, based on data such as measured indoor, outdoor, and energy price conditions.
I think of these algorithms as an upgrade to supervisory control sequences via intelligently and automatically overriding setpoints. Historically, they’ve focused on HVAC only. And within HVAC, they’ve targeted only a few setpoints per solution. Early pioneers like BuildingIQ focus on the air side by overriding space temperature setpoints and air handling unit static pressure setpoints. On the water side, chilled water plant optimization controllers like those from Optimum Energy or Conserve IT or Automated Logic or Siemens, focus only on setpoints like the chilled water temperature or condenser water temperature.
These original algorithms optimized sequences using techniques similar to traditional trim-and-respond sequences, but they came from the overlay instead of the BAS. Newer players like Kinetic Buildings, Verdigris, Honeywell’s Forge Energy Optimization, BrainBox AI, Smart Locus, and Yardi are targeting all HVAC sequences in one overlay package.
These products attempt to modulate HVAC systems and ramp equipment down as much as possible at any given time. There’s always going to be a limit where further modulation will result in a failure to meet the system-of-system’s requirements. ASO algorithms attempt to keep systems at exactly that limit as much of the time as possible.
Finding this optimal setpoint is a great application for machine learning. The goals of building control often conflict with each other, especially as more and more systems are integrated together. Finding the optimal setpoints, given all of the known tradeoffs, is nothing but a big hairy math problem. Humans could do this math, but it would take too long. And by the time they finish, the results would be out of date.
In the future, the math problems are only going to get hairier. First, consider the changes happening to the electric grid:
Next, consider the evolving demands of building occupants and operators:
Tomorrow’s overlay solutions will expand far beyond temperature and humidity control sequences to address these multiple conflicting demands and growing expectations in intelligent ways. Based on my research, here’s my best crack at summarizing and generalizing them:
As with all new technology, there are early adopters and there are skeptics. I’ve talked to leaders in both camps and heard three main arguments against advanced supervisory control solutions. Let’s attempt to summarize the skeptics.
The first argument is that supervisory control 1.0 works just fine. If a building’s setpoints, sequences, and schedules are optimized, that would capture 80% of the potential energy savings. No overlay needed. And if you need an overlay, it would be something like FDD to help keep the optimized supervisory settings in place. Any new technology added to an optimized stack would see diminishing returns. When ASC upstarts claim these algorithms save 15-20%, the skeptics wonder how much of those savings would have been realized with a simple and traditional control sequence.
The second argument is that most buildings are nowhere near ready for this technology. Their control systems and other building systems are not ready for two-way communication. Their building operators are not ready to stop actively operating. Their systems are not in the physical shape needed to allow true automation. Buildings, just like humans, have what one reader called a “hierarchy of needs”, of which ASC is the pinnacle need. Here’s my quick attempt at capturing the hierarchy:
They need basic needs fulfilled before pursuing the pinnacle makes sense. So when ASC vendors claim their solution “self-installs” or is “as easy to set up as an LED light bulb” or they’re “not looking to get involved in change management”, skeptics are thinking, “this isn’t going to work”.
The third argument is that controlling buildings from the cloud won’t work. Skeptics say the connections aren’t reliable enough. When the connection drops, ASO technologies are forced to relinquish control back to the underlying controllers. If you're depending on this type of control to capture energy and demand savings, they’re only going to be as good as (1) the underlying/original control sequence and (2) the connection to the cloud. ¹
The US General Services Administration (GSA) did a pilot project with BuildingIQ a few years ago that certainly backs up the three arguments above. Here’s a summary:
I would also like to add a fourth piece of skepticism to the hat. I predict the un-explainability of new and fancy ASC control sequences to be a significant obstacle. One pilot project I’m working on right now includes a control sequence modification called “intra-day adjustments to the air handler speed” based on whole building occupancy. When I asked the vendor how this sequence will work without starving some occupied zones of the necessary static pressure to keep them minimally ventilated, they were unable to answer. Apparently that’s the AI’s job.
I have at least one foot firmly rooted in the skeptics’ camp. I’m also quite bullish on these new technologies. How can that be? Let’s continue.
Despite my skepticism and agreement with those of you who have brilliantly poked holes in the value proposition for ASC, I don’t think you should ignore these solutions. Quite the opposite—I think we need them and we need you to play a role in implementing them strategically. Let’s zero in on the first two skeptic arguments: diminishing returns and the hierarchy of needs problem.
For me, this argument evaporates when I think about the hundreds of buildings I’ve walked, audited, or retro-commissioned. In very few of those was supervisory control working just fine. Quite the opposite—the existing supervisory control paradigm is broken. It simply doesn’t work in practice. That’s why there are still such huge opportunities for overlay solutions like FDD and MBCx—solutions that have barely scratched the surface of their potential.
If we agree on that, then the question is what to do about it. The old answer was to put FDD in, identify the faulty sequence or setpoint or schedule, then pay the incumbent BAS vendor to do it right. In my experience, that’s very expensive. And often the fix is just as bad. The list of faults piles up while everyone bangs their head against the wall. With ASC, the new answer could be: put an overlay on top of the BAS with all the optimization algorithms and setpoint standards built-in. With a standardized data model, those built-in algorithms and standards can be scalable and portable to every building in the portfolio (and the next portfolio).
One thing to consider here is whether the Overlay 1.0 business model stands in the way of the acceptance of ASC. If the value proposition of FDD or MBCx depends on claiming 80% of the potential savings, then ASC is going to feel like a threat to providers of those solutions and they might write it off as “diminishing returns”. It’s encroaching on their quick-payback-with-optimization turf and providing another option. Food for thought.
When you look at the pyramid, you’ll see everything beyond the first level depends on and interacts with the control system(s). I think the hierarchy of needs argument falls short because it views each building block of the pyramid as separate from everything else. It ends up looking like this:
This mindset creates more and more silos. Our industry doesn’t need more silos. Open data, RCx, MBCx, FDD, and even ASC are all completely dependent on the performance of the underlying BAS. When they’re viewed separately, there’s a lack of accountability for the actual performance of the building. It’s always someone else’s problem. We often hear, “you touch it, you own it.” Well, who actually owns it?
As more and more systems are integrated together, we need to let our habit of silo-creating fall by the wayside and start thinking about the building as one system. Controls and the optimization of the controls are really two sides of the same coin. With that mindset shift, the hierarchy mental model evaporates.
Suddenly an ASC strategy could be a part of every smart building strategy. For example, when you’re opening up the data in the building, it could be done in a way that allows two-way communication. We set the industry back further when the integration is done in a way that only allows a one-way pull of data. Once the data is opened up, RCx and MBCx and FDD are going to uncover supervisory control issues. With ASC in mind, issues could be fixed in the most efficient or sustainable way. Or fixed automatically.
In the next and final installment, we’ll pull all of this together. How might building owners approach ASC strategically?
¹ Not all solutions in this space need a cloud connection. Chilled water plant optimization controllers/servers are designed to operate locally.
Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.