The following presentation provides an overview of OpenADR, the nebland software NOVA VEN stack, and changes to the California Title 24 code with regard to OpenADR. Contact us below for more information.
Title 24 in 2020
The next iteration of California’s Title 24 code specifies new demand response requirements. For both residential and nonresidential, demand response controls must support OpenADR and VENs must be OpenADR certified. VENs can be onsite or offsite/in the cloud offering more choice to consumers and demand response program designers alike. The new code goes into effect January 1st, 2020.
If you’re interested in implementing OpenADR, please send us a message through the contact form at the end of this article. Our NOVA VEN will put you on a fast track to a certified solution.
Visit the California Energy Commission Building Energy Efficiency Program page for more information regarding Title 24.
Demand response controls w/OpenADR
The previous version of the Title 24 code is lite on details regarding how demand response must be implemented in residential and nonresidential settings. The code simply states that sites must have the ability to receive and respond to demand response signals. What the code doesn’t specify is how signals are sent to the site. The new code makes it clear: demand response controls must support OpenADR.
OpenADR is a simple demand response protocol which defines how signals can be sent from a demand response server (VTN) to a demand response client (VEN). OpenADR has two profiles: the simple 2.0a profile supports only simple demand response events, while the more feature full 2.0b profile adds more event types, telemetry reports, and a few other features. Controls can use either profile, though offsite and cloud based VENs must implement 2.0b.
With OpenADR specified as the demand response protocol, we now know how demand response signals will be sent to the site.
Meeting Title 24 demand response requirements
The California Energy Commission published two manuals titled RESIDENTIAL COMPLIANCE MANUAL FOR THE 2019 BUILDING ENERGY EFFICIENCY STANDARDS and NONRESIDENTIAL COMPLIANCE MANUAL FOR THE 2019 BUILDING ENERGY EFFICIENCY STANDARDS which, among other items, prescribe the demand response requirements. These files can be downloaded from the Building Energy Efficiency Program link found in the intro.
Both documents provide two options for meeting the communication requirements for demand response controls:
- Option A: Install an OpenADR 2.0a or 2.0b certified VEN within the building as part of the DR control system
- Option B: Install a DR control system that has been certified to the Energy Commission as being capable of communicating with an OpenADR 2.0b certified VEN (emphasis added)
The phrase communicating with in option B above is a bit ambiguous, but the intention is to allow offsite or cloud based VENs. The nonresidential compliance document continues with the following clarifying text:
If using Option B, the VEN may be separately located on-site, offsite or in the cloud …
–2019 NONRESIDENTIAL COMPLIANCE MANUAL, page 744 (D-4, Appendix D – Demand Responsive Controls)
This wording is completely unambiguous. The residential compliance document, on the other hand, does not contain wording that is this clear, but I was able to get clarification from Peter Strait, Supervisor, Building Standards Office. Through an email exchange, Mr Strait stated:
I am not aware of a circumstance where use of a cloud-based VEN is prohibited, provided that all of the applicable specifications are met.
— Peter Strait, Supervisor Building Standards Office
Cloud based VENs have an additional CEC certification requirement: vendors must complete a document which certifies their product communicates with a certified 2.0b VEN. This document was not yet available at the time this article was published.
The case for cloud based VENs
Whether or not cloud based VENs should be allowed is a hotly debated topic. The main argument against allowing cloud based VENs is one of stranded assets: if a provider goes out of business and the only way to communicate to the devices is through the provider’s cloud, the device will no longer be available to the utility for demand response.
This is a valid argument for utilities but it ignores the fact that a consumer will choose a device not because it has demand response capabilities, but because it provides some convenience (such as the ability to remotely control a thermostat). If the consumer’s only reason to connect a device to their home network is for demand response, they will be less likely to notice if the device disconnects from their network (and loses connectivity to the utility), and also less likely to take the time to reconnect the device (how do I do this again?).
There are technical reasons to allow cloud based VENs. Some of the less expensive thermostats have very limited computing resources and simply can’t run a VEN, or the cost of developing a VEN for such a device is too high. From a provider perspective, it’s likely far easier to implement a cloud based VEN and use their existing infrastructure to remotely control the device. Even providers with devices that have the resources to run a VEN on device may choose to run in the cloud instead because it’s easier/faster/cheaper to do.
Another technical reason is one of scale. Cloud based VENs are often running in an aggregator mode where one VEN controls many end devices. This greatly reduces the number of VENs connected to the VTN and moves the burden of computing resources from the utility to the device provider. Since the device provider already has the infrastructure in place to communicate to their devices, adding OpenADR to their service adds very little overhead, whereas utilities will need to build out infrastructure.
There are situations where an onsite VEN is the optimal choice, but it’s great to see that cloud based VENs are allowed in situations where it makes sense. This gives all involved more choices.
Regardless of where the VEN is running, it must be certified by the OpenADR alliance.
To get a product certified, vendors must be a member of the OpenADR alliance. Alliance members can get products certified by submitting their solution to an alliance approved test house for compliance testing. Certified products are listed on the alliance website. Here’s a link to the nebland software NOVA VEN and NOVA DRE VTN product listings for example.
Some vendors claim to have a “compliant” solution, but this is not a term recognized by the alliance. There’s only one way to get a product listed on the alliance website and that’s through the certification process. The Title 24 code change makes it clear that VENs must be certified and the alliance website provides a convenient location to find certified products.
Being OpenADR certified does not automatically mean your device meets the California building codes. Before getting OpenADR certified, be sure your device meets the other requirements as well. Refer to the California Energy Commission website for more information.
Implementing OpenADR with NOVA
If you’re looking to add OpenADR to your portfolio, our NOVA VEN software can easily integrate on device or in the cloud. Contact us below for more information.