Cloud VENs - a new OpenADR architecture for IoT devices

What we mean by "Cloud VEN", and why this is now the dominant OpenADR implementation model

6 minute read ∙ Jul 2nd, 2021

The cloud-based Virtual End Node (VEN) is an architecture for implementing OpenADR VENs that has become the dominant implementation model over the last few years. This article is a summary of what we mean by Cloud VEN, what has been driving the shift to this implementation model and some implications of the new architecture. It mirrors and adds to the talk we gave at the recent OpenADR Summit (day 2).

What we mean by Cloud VEN

To compare against the newer "Cloud VEN" model, let's start by describing what we will call the "traditional" OpenADR model. OpenADR was developed between 10 and 20 years ago when demand response was primarily occasional load sheds fulfilled by large commercial and industrial buildings. It pre-dated the proliferation of IoT devices and the increasing use of load flexibility as a more dynamic resource, and while it can accommodate these trends it was not designed with them in mind.

In the traditional model shown by this diagram, the VEN is a piece of hardware installed onsite, usually in a commercial or industrial site. Examples of VENs that fulfill this model are the the ISY or the EISSBox. The VEN has an interface to connect to the VTN and is programmed to pass load shifting events to and receive data from the local building controls system.

Functionally, the Cloud VEN architecture operates similarly to the traditional model: the VEN is the interaction layer with the VTN and interfaces with the local system. Instead of being deployed on-site in a piece of dedicated hardware, it is deployed as pure software and typically in a cloud platform such as AWS, Azure or Google Cloud.

The main functional difference is that a cloud VEN will typically be the interface for controlling across many different sites in a utility territory, versus the traditional model where you would have one VEN per site. When a Cloud VEN receives an event, they subsequently control all of the devices that they know are participating in that program. When a Cloud VEN receives a report request, it can query their database for all of the devices in the program and provide data either for individual devices or in aggregate.

Why cloud VENs?

The list of certified OpenADR products can be found at products.openadr.org, which is by default ordered so that the most recently certified products show up first. By looking at the recent VEN entries, it is easy to tell that Cloud VENs are currently most common, whether they are implemented using a software package like Plaid or built from scratch. This wasn't the case for the first round of OpenADR VENs, so what changed?

Good fit with IoT devices

For context, Nest was founded in 2010. 10 years ago, a typical energy management system was run on a computer on-site with various devices connected into it. Most devices and appliances had no internet connection. So, if you wanted to connect these loads to an internet server to, for example, receive demand response events, you would have to add something extra to link to that device to the load management server. The hardware model was the way to do that.

Now, most devices being installed are internet connected by default and have full monitoring and controls systems already in place, so adding an OpenADR connection down to the individual device is duplicative. It is simpler and more scalable to use the existing controls for the individual device and add the VEN upstream.

Good fit with smaller form factor, more numerous device types (e.g. residential)

When average demand is upwards of 100s of kWs per site, the value of the load is high enough that the investment required to install and program a hardware VEN is easily worth it. From the VTN's point of view, they only need to manage a handful of VENs to achieve significant load shifting capacity.

However, when a device is a residential thermostat which controls perhaps 1kW, the value of that load is quite a lot lower. At this scale, the cost to install and manage them would not be worth it if each device had a VEN attached. Having one VEN representing many devices makes programs easier to scale without the VTN having to add and manage many thousands of VENs by itself.

Easier to develop on-cloud

Even though devices are so much more capable than they were 10 years ago, developing and maintaining on-device software is still much more difficult. Developing software in the cloud provides full flexibility with regards to language, operating systems, devops, integration with current platforms, etc., leading to lower development cost.

Allowed by regulations and requirements

OpenADR implementation is often driven by regulatory (for example, California Title 24, Appendix H) and/or demand response program requirements (for example, SCE's Charge Ready program). In the past few years it has gone from being implicitly to explicitly understood that Cloud based VENs fit the requirements for these programs and mandates.

Practically speaking, if an on-cloud implementation is easier than on-device for an OEM and it is allowed by programs then it's not surprising that it has become the dominant implementation model.

What are some downsides of cloud VENs?

The above describes many benefits of cloud-based VENs, but this model does introduce a break from the past in a couple of ways.

Broadly, OpenADR is understood have two key areas of value:

1. Lowering integration costs: provide a "common tongue" for utilities and loads to communicate, so that every automated integration is not a fully custom job
2. Avoiding stranded assets: with the traditional model, the site maintains control over their loads and their connection to the VTN. If the VEN manufacturer goes out of business, the site manager can still use the VEN to communicate with the VTN. Or if they can't, they can switch it out with another VEN and continue participating.

Lowering integration costs is the key value proposition. But, the stranded assets issue still occasionally comes up in conversation if not in practice.

Stranding assets

By implementing cloud based VENs you no longer avoid stranded assets - if the OEM goes out of business or stops operating their VEN, you lose access to those devices in the field. Therefore, sometimes program managers and utilities can be concerned about the use of Cloud VENs in their programs.

However, being dogmatic about stranded asset concerns means not taking advantage of all the scalability benefits enabled by the IoT model since IoT devices are never going to solve for stranded assets - if the OEM goes out of business the full device will cease to function properly anyway, and the DR program will be the least of the customer's concern. Rather, practitioners should consider at what point stranded assets should be a concern. For example, on one end of the spectrum a residential thermostat should not be a stranded asset concern, while on the other end a 40 MW water pump probably should be.

Given the benefits of cloud-based VENs, we are generally seeing a pragmatic approach and are not aware of any programs that do not allow for their use.

Not getting as low integration costs as we should

Cloud-based VENs should lower integration costs even more than in the traditional model, because you get the device controls infrastructure, connectivity resolutions, function sets - i.e. the things that make device management and automation hard - more or less for free and at scale. In reality, we have seen practices that lead to this not always being the case. Cloud-based VENs generally allow for a lot more flexibility, so VTN providers are taking advantage of that, which increases integration costs.

This blog post is already too long, so we will wait for a future post to describe the practices we have seen that decrease interoperability and increase integration costs, and what could be done to resolve them.