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.
We’ve noticed a gap in the market for an affordable, production ready VTN. To meet demand, we’re offering a yearly license in exchange for regular updates and support for the EPRI VTN. The updates will address issues related to running the VTN in a production like environment aimed at pilots using thousands of VENs. Space in the program is limited so contact us soon!
Issues with the EPRI VTN
OpenADR has been gaining favor as the goto demand response protocol for programs throughout the US with Europe and Japan also showing strong interest. California is providing an especially strong push for demand response and distributed energy resources in general with the EPIC Program and longer term pilots such as the Southern California Edison Charge Ready Program requiring a 10 year commitment. Smaller utilities, Municipals, Coops and other companies interested in demand response are doing their own testing with freely available and low cost tools such as the EPRI VTN, the Quality Logic cloud based VTN, or the nebland software virtual machine appliance. Customers are starting to ask the question: how do I move from lab testing to pilots using these tools?
The short answer is, in its current form, the EPRI VTN is not well suited for day to day operations for a long(er) term pilot connected to many VENs. But we’re changing that. Here are some issues that need to be addressed:
- High availability installation instructions and best practices
- Performance issues apparent when dealing with thousands of devices
- Improve the API feature and provide detailed documentation for integrating with 3rd party systems
- Compliance testing
We’ll address these issues and make the changes available to licensed customers through regularly scheduled releases. We’re opening enrollment to 5 companies but only 2 spots remain. Depending on feedback, we’ll open up enrollment to a few more customers starting in January of 2018 on a first come, first serve basis. Use the contact form at the bottom of this page to claim your spot.
Read on for details of the issues and how we intend to address them.
When delivered over http, an OpenADR VTN can install and scale like any other web application. This basically means an http load balancer in front of multiple front end instances and a scalable database in the back. We will test different setups and collect performance data with the nebland software VTN load testing system, and provide instructions and recommendations for performing a high availability installation and handling day to day operations.
Performance issues we’ve seen fall into the following categories: inefficient event generation, java singleton issue, torquebox cpu and memory consumption, interval data storage and retrieval.
Inefficient Event Generation
When generating an event, the VTN does a blocking call and generates an event for every VEN target. This means the user will be stuck with a non-responsive UI waiting for event generation to complete.
In many situations, the event payload is exactly the same for every VEN target so there’s no need to generate the same message multiple times. When targeting a small amount of VENs, this isn’t a problem, but as the number of targeted VENs increases, so does the time needed to generate the message. This provides a bad user experience at best, and can simply timeout and fail at worst, giving the user an unfriendly error message. Two changes need to be made: 1) Move event generation to a background processor, and 2) If no VEN specific information such as VEN ID or Party ID are located in the event, the event message will only be generated once.
A Java singleton is used throughout the code for converting between Java POJOs that can be converted to and from XML, and ruby active record objects. This interaction between Java and Jruby is very resource intensive. The singleton object with locks was required because the object isn’t threadsafe, and there’s an enormous performance hit when creating the object. The locked signleton objects means only one VEN can receive data at a time – no matter how many threads are available.
The solution: move everything related to message handling to a separate java process. This will immediately improve performance by avoiding the interaction between Java and Jruby, and this model is easier to scale. Separating the code will make it easier to refactor the Java code to take advantage of multiple threads.
Moving the Java code out of the core app has additional benefits. Using Java in Jruby has proven to be very cumbersome due to the complexity of Java. Separating the code will make both the Rails code Java code easier to reason about, and the two components can be tested independently.
Torquebox Resource Usage
Torquebox has been a pain point for a number of reasons: it’s slow to start, it uses lots of CPU and memory, and most importantly: support seems to be fading. The bottom line is: torquebox must go. Resolution of the previous issue will create a separation between the Java code and Rails code which means we will be able to switch to standard ruby and use one of the more popular Rails application servers.
One of the larger obstacles to making the system more performant is handling interval data both in storage and retrieval. Instead of a traditional RDBMS, we’ll explore using a time series database such as InfluxDB which is much better suited for handling this type of data. Installations that don’t use a lot of interval data should work just fine with a traditional RDBMS, however, so the use of a time series database should be optional.
The Rails code has performance issues related to converting many database records into Ruby objects (e.g. when generating charts). We’ll explore options to improve this performance.
Improved API Feature
The VTN includes an extensible API feature for integration with 3rd party systems. Documentation for this feature is basically non-existent, there are no concrete examples demonstrating how to use the feature, and it needs authentication and authorization. We’ll address all of these issues.
The first release of the EPRI VTN was compliance tested but subsequent releases have not been. The latest release should still be compliant, but there’s no guarantee. We will use our automated instance of the Quality Logic testharness to integrate running the compliance tests with our release process, and guarantee that each release passes all compliance tests.
What we’re offering
In exchange for a yearly license fee, we’re offering access to the above improvements as they’re implemented as well as a few hours of support to help you manage your instances.
This project won’t happen overnight. We’re planning this work to happen over the next two years, but if there’s enough interest, we’ll accelerate the time line. Space is limited so don’t hesitate to contact us!
Introducing NOVA, an OpenADR 2.0b VEN software stack by nebland software. NOVA adds OpenADR functionality to a wide range of systems: run in the cloud or your IoT.
NOVA is based on the open source software developed for EPRI by nebland software. While the EPRI software is an excellent starting point for developing a VEN, it has two key issues:
- It’s missing features required for OpenADR compliance
- As a standalone library, it can’t be compliance tested
We’ve added the missing features to the library and developed a standalone server. By turning it into a server, the complete stack can be compliance tested. Systems integrated with NOVA don’t need to go through the full certification process which translates to significant cost savings.
As a standalone server, NOVA integrates with any programming language through RPC. RPC options include HTTP, named pipes, message queues, shared memory, database, etc. Looking for a more integrated solution? NOVA can be loaded as a shared library.
Contact us to learn more.
Over the past few years, I’ve been working on software and devices which use the OpenADR and CTA2045 demand response protocols. The software and hardware are being used in research projects in the ESIF lab at NREL, and are part of a new wave of devices which will offer automated demand response capabilities to consumers.
This is the first article in a two part series. In this first post, we’ll cover demand response from a high level and discuss how consumers can benefit from IoT devices that support demand response. In the second, part we’ll dig a little deeper into how the OpenADR and CTA2045 protocols can be used to implement demand response.
For those that don’t know, an IoT device is an Internet connected device. As an undergrad in computer science, I recall professors saying things like, with IPv6, your toaster will have an IP address, and computers will fit in your pocket, both of which seemed like strange concepts at the time. While my toaster is not connected to the Internet, I do have a computer in my pocket and have the ability to remotely monitor and control my home’s temperature through a connected thermostat. Suddenly, the usefulness of connected devices (IoT) is taking shape.
Demand response is the act of reducing energy use when the cost of energy is high. The cost of energy fluctuates in response to the amount of energy available. Many consumers pay a flat rate for energy and aren’t affected by fluctuating costs, but more utilities are offering variable rates which take into account these fluctuating costs. Variable rates encourage consumers to shift energy use to times when less energy is being consumed. For example, consumers on a variable rate might run the dryer on nights or weekends instead of during the day. Programmable thermostats can also help shift energy use.
Another aspect of demand response involves sudden changes in the power grid which further reduces the amount of energy available. Since the demand for power remains the same during such an event but the amount of power available goes down, the cost goes up. Given these types of events are unforeseen, shifting energy use doesn’t solve the problem. Instead, devices receive a signal in realtime when such an event occurs, and the device responds automatically by reducing energy use. This is called Automated Demand Response and IoT device makers are exploring options to implement it.
Automated Demand Response
To be viable, a combined automated demand response/IoT system needs to be flexible: the device must be compatible with any utility. Put another way, changing rates or utilities must not require changing devices. Open protocols are one path towards this needed flexibility.
A demand response protocol called OpenADR – Open Automated Demand Response – aims to fill this need. OpenADR is an open protocol which means it is unencumbered by patents and can be implemented by anyone. OpenADR products are certified by a third party which helps ensure interoperability among vendors. The OpenADR website has a list of certified products.
IoT and Automated Demand Response for Consumers
Utilities across the US are running pilots which utilize IoT devices and OpenADR. California in particular is a proponent of OpenADR in a big way, requiring the use of OpenADR in many new utility pilots and programs. Many types of devices are being tested, including thermostats, water heaters, car chargers, and pool pumps.
It’s clear consumers are welcoming IoT devices, but will they welcome utilities or other third parties to control their devices in the name of automated demand response? This is a new interaction which raises additional security issues.
IoT and automated demand response combined will give consumers more control over their energy footprint and help manage energy costs for both the utility and consumer. Unsure if your IoT device supports demand response? Be assured that companies selling IoT devices today are exploring options for automated demand response for tomorrow.