California Title 24 Embraces Cloud Based Vens
Apr 8th, 2019
California Title 24 Embraces Cloud Based Vens
Apr 8th, 2019
Title 24 in 2020
The update of California’s Title 24 code that goes into effect in 2020 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 to comply with title 24, our Plaid VEN will put you on a fast track to a certified solution.
Full information on Title 24 is available from the California Energy Commission Building Energy Efficiency Program.
Demand response controls w/OpenADR
The previous version of the Title 24 code is light on details regarding how demand response must be implemented in residential and nonresidential settings. The code simply stated that sites must have the ability to receive and respond to demand response signals. What the old code didn'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
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
The case for cloud based VENs
Early implementations of OpenADR defaulted to having a VEN on site or on device. Cloud based VENs are now more normalized and we have seen most companies choose this implementation model. Utilities have historically preferred on-device VENs, hoping that there would not be a 'gatekeeper' to controlling the device. However, especially at the residential level, it has become clear that asking device owners to manage the utility relationship is generally impractical and hard to scale.
Cloud based VENs typically offer a simpler technical solution. Many product manufacturers already have existing infrastructure to remotely control the device, so a cloud-based VEN can become a part of that existing infrastructure. This is a lot more scalable than putting a VEN on every device. In addition, some devices are not set up for runnia VEN. For example, 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.
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 would need to build out infrastructure to accomplish the same goal.
There are situations where an onsite VEN is the optimal choice, but it’s great to see that cloud based VENs are allowed and embraced, so they can be implemented in situations where it makes sense.
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.
Some vendors claim to have a “compliant” solution, but this is not a term recognized by the alliance. The only way to get a product listed on the alliance website is 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.
Implementing OpenADR with Plaid
If you’re looking to add OpenADR 2.0b to your portfolio, our Plaid VEN can easily integrate on device or in the cloud.