implement-nova.5

Implementing OpenADR with NOVA

NOVA OpenADR VEN Stack

The nebland software NOVA VEN stack provides our customers a fast path to a compliant OpenADR 2.0b VEN. Dozens of companies have implemented NOVA on device or in the cloud. Some of our customers manufacture or manage thermostats, car chargers, lights and lighting controllers, energy management gateways and other devices, while others offer energy management/building management solutions. This wide customer base shows both the broad applicability of OpenADR, and also the flexibility of our software to integrate with customer systems.

How is this flexibility achieved? Through a microservice architecture.

Integrating with a Microservice

NOVA is a microservice which runs as a standalone executable. It exposes an API for sending messages to NOVA, and uses a customer written communication plugin for communicating to the external system.
NOVA ARCHITECTURE

Here are two benefits of a microservice approach:

  1. Microservice integration is language agnostic. The external system can be written in any language using any tools with the only requirement being that it expose an API.
  2. With the OpenADR driver running separate from the external system, there’s a clean separation of concerns. Microservices promote loose coupling, allowing the two systems to be tested and developed independently.

Companies that have demand response capabilities are able to implement NOVA very quickly. We’ve helped companies from inception to implementation to compliance testing in as little as 2 weeks, but time frames from 1 to 2 months are more typical.

Implementing an OpenADR VEN 2.0b w/NOVA

NOVA provides a complete implementation of OpenADR and it’s certified by the OpenADR alliance. ALL of the OpenADR logic resides within NOVA. The customer system integrates with NOVA by implementing business logic: namely determining what devices to control and what type of control to perform during an event, and collecting telemetry data for reports. This functionality touches on two OpenADR services: EiEvent and EiReport.

There are many conformance rules that govern the interaction between a VEN and VTN regarding events and reports. Our customers don’t have to worry about any of them. Instead, requirements for implementing OpenADR are slimmed down to the following:

  1. Start control when an event starts
  2. End control when an event ends
  3. Query report data
  4. Asynchronous opt in/out of an event

That’s it! To implement OpenADR, the customer creates a simple communication plugin using simple APIs while the complex OpenADR logic, XML message formatting, and communication to the VTN is completely hidden and handled within NOVA.

Looking for More?

For information about OpenADR, visit the OpenADR Alliance website and see our OpenADR Overview presentation.

If you’d like to learn more about NOVA, contact us through the form below.

oadr-symbol.2

OpenADR Overview

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.

t24oadrcloud11

California Title 24 Embraces Cloud Based VENs

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.

OpenADR Certification

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.