Last week saw a host of companies launch products and platforms enabled to deliver the latest version of OpenADR, the technology meant to standardize fast and reliable automated demand response. There’s plenty of information out there about how utilities, grid operators and third-party aggregators are using automated demand response, including OpenADR, to achieve their goals.

But what about the building side of the equation? Each building, whether it be a factory, office complex, or a humble home, has a different way to interpret, act on, and verify what it’s done to shed energy use in response to these automated signals. Closing that loop is also critical for utilities that want to know just how much power use reduction, at what speeds and levels of reliability, it’s getting out of the price signals and power-down commands that are being sent out.

Last week, Honeywell announced a new gateway for its ComfortPoint building automation system, one that’s compliant with OpenADR 2.0b, the most recent iteration of the technology. I talked with Ed Koch, co-founder and CTO of Akuacom and senior fellow in Honeywell’s building solutions business, to learn how this functionality is being applied at the building level.

A Taxonomy of Building Commands

First of all, as a “virtual end node,” or VEN, Honeywell’s gateway is “in and of itself not a building control system -- it doesn’t control loads itself,” he said. “But it does allow the existing building management system to interface with the utility’s VTN, and also send telemetry back to the VTN,” he said, referring to the “virtual top nodes” that send the signals from utility to customers.

From there, the gateway talks to building management systems (BMS) using a variety of standards such as BACnet and ModBus, which means it can interact with Honeywell systems or the wider world of competing building systems from Johnson Controls, Siemens and many others.

So what is it asking those buildings to do? “There’s kind of a taxonomy that the industry is starting to coalesce around, about how you classify these different interactions,” he said.

“At the very highest layer, the utility might want to influence what a resource does, by using incentives. What that basically boils down to is prices,” he said. In other words, sending changing power-price signals allows the BMS to change temperature set points, cycle HVAC systems, dim lights or even take elevators and escalators out of service, all to reduce power use, and thus, to save money.

“The next level of interaction is, they’re actually giving the resources some instructions or guidance on how it wants it to change its load profile,” he said. In other words, this is a request for a specific amount of power reduction it’s seeking from an individual building, or “resource,” in DR parlance.

“It still doesn’t specifically state how it’s supposed to shed that,” he said, “but that’s obviously different than an incentive -- it’s more specific.” These are the kinds of interactions that might allow a building to play a role in ancillary services markets, which traditionally rely on dispatchable power resources to meet grid needs.

“The third type is more direct load control type interactions, reaching further into the building, and giving instructions to different loads,” he added. That’s largely for smaller commercial or residential customers that don’t have complex building management systems, but can afford OpenADR-enabled devices, such as, say, Honeywell’s new line of thermostats.

Closing the Loop via “DR Logic”

As for getting the building in question to turn these commands into predictable and verifiable power use reductions, “It all comes down to where the so-called DR logic resides,” he said. “That’s the set of logic that translates the signals to actual load commands.”

For large commercial and industrial programs, “that logic tends to reside more in the building -- they have more staff, more money, more sophisticated systems.” That’s the place where VEN-to-BMS interactions become critical in assuring outcomes that the utility is seeking from its programs.

One of the key differences between OpenADR 1.0 and the newer 2.0 versions is in handling this flow of information back from the buildings, he said. This function, or “reporting service,” is now a lot more robust, and can handle real-time results from end users, whether that’s meter or submeter data from big buildings that can confirm real-time energy consumption changes, or simple verification that a home or small business thermostat or load-control device has in fact gotten the signal and has done what it’s supposed to do.

It’s still a lot more complicated to translate different price points into different levels of power reduction than it is to send specific power-down commands and verify the result, he noted. Honeywell is working on this challenge, both in the design of specific building products that can receive, react and verify results of OpenADR signals, and via services support that can help building managers program and maintain their buildings to make the most out of their demand response potential.

“Another thing we focused our attention on was fast DR,” he added. “Fast DR is dealing with what I’d call dispatchable resources -- you expect the resource to respond immediately to that signal.”

Just how fast that is depends on the ancillary services program the building wants to play into, of course. Some of the most lucrative programs, such as frequency regulation response, require responses in about four seconds, while less stringent programs like non-spinning reserves may allow up to ten minutes for a response. But in either case, “The point is, you’re not sending some advance notification,” as many traditional DR programs do with day-ahead or hour-ahead dispatch calls.

To verify that buildings have actually followed through on these commands, of course, requires close to real-time telemetry coming back from the building to the utility. “They need to see in real time what those responses are,” he said. “It’s more like a control system.”

Fast, automated demand response is still in its infancy, and right now, it’s typically limited to sophisticated, more or less purpose-built implementations. But the whole goal of the OpenADR process is to make the core capabilities available to the mass market, Koch said.

“But what’s happening now, because we have standardization, there's going to be more of a pull,” Koch said. “With more vendors out there, with more products that support demand response, you’ll have more customers who will be more proactively seeking out revenue opportunities than they have in the past.”

Just how quickly that concept takes hold relies as much on utilities setting up programs that allow greater participation as it does on the proliferation of technology in buildings. As last year’s report on Honeywell’s project with PG&E and LBNL (PDF) makes clear, inaccurate and slow-reacting commercial building loads are still considerable concerns for utilities seeking to rely on automated demand response assets.

Likewise, while California’s big three utilities are testing their first commercial pilots of OpenADR 2.0 systems this fall, it’s still unclear how quickly those offerings will translate into broader openings for non-traditional demand response participants.

That doesn’t mean that demand response companies aren’t building OpenADR into their offerings -- EnerNOC, for one, announced last week that it’s also built OpenADR 2.0b into its platform.

But as of yet, “It’s really a nascent standard, and we’re not seeing a lot of domestic activity, or a lot of domestic interest,” Gregg Dixon, senior vice president of marketing for the Boston-based company, said in an interview this week. “We’ll see how much of an impact it has on the market.”

On the other hand, EnerNOC is seeing more interest in the technology from overseas, he said. That’s likely because the U.S. has a relatively mature existing demand response infrastructure, while Europe and Asia are just starting on that process, he added.