Cloud VENs and interoperability

Interoperability is the key to reducing integration costs. This post describes some key issues and opportunities particular to Cloud VENs.

3 minute read ∙ Jul 15th, 2021

As described in a previous blog post, cloud-based VENs are now the most common implementation model for OpenADR, and offer flexibility and scalability benefits for demand response programs. OpenADR provides the benefit of a common language, so rather than every utility creating a custom integration with every OEM, integrations are standardized and may be re-used. This is referred to as interoperability.

Peak interoperability is a true plug and play integration, where an OEM and/or device owner can give permission to a 3rd party (i.e. a utility) to control their devices during a load shifting event and it "just works" - no custom integration required by the OEM. In practice we are a long way away from that, but even if we don't achieve it any time soon there is a lot that we can work on to reduce integration costs.

Interoperability challenges

The two factors that lead to higher integration costs are:

1. The complexity of any given integration between a utility and device/OEM
2. The variability of integration requirements between programs

In other words, integration costs are higher both when you need to do a lot of work to integrate with a given utility and/or if you have to start from scratch every time. #1 can be improved with careful consideration about what is necessary vs what is just "nice to have", and #2 can be improved by coordinating between utilities to align on the same requirements.

With Cloud VENs in particular these factors can be exacerbated for two main reasons:

1. The range of possible types and distribution of devices to control is wider with cloud VENs, so there are many more possible ways to integrate with them and therefore more opportunities to increase complexity.
2. Cloud VENs have not been used for as long as hardware VENs, so their use has not been "formalized" and tends to vary more between different programs.

Utility programs differ in many ways: they use different event types, have different requirements for reporting, may or may not target end devices individually, may or may not use event opt outs, etc. So, while the use of OpenADR does at least standardize around a common language and reduce integration costs vs not using it, the way programs use OpenADR differs so that each integration each still requires custom work for OEMs.

It is important to note that OpenADR does not have the goal of plug and play interoperability, so this is not a design flaw in the protocol. OpenADR defines a relatively broad range of possibilities and it is up to practitioners to decide which parts to use for their program.

How can we improve interoperability?

Achieving true interoperability given only the default design of OpenADR is impossible. Even if a VEN manufacturer tried to account for every possible defined event and report type, VTN users could still create custom event types and reports, or create specific guidelines around how to use them.

The practical approach is for utilities to align around particular ways to use OpenADR.

The OpenADR program guides are a good start to this. They define specific ways of using the protocol to implement certain types of programs, from common types of DR programs in California to newer EV charging or DER load shifting programs. But in practice, we have seen them used more as an educational tool to understand possible ways to use the protocol rather than as a way to structure and design programs.

True interoperability would require completely prescriptive use profiles, so there is no ambiguity about what the device needs to do, and a testing program that confirms that the device does in fact fulfill that need. The more specific testing would give utilities confidence that the devices can do what they claim and would give OEMs something concrete to work towards.

Most importantly, it would require a significant number of utilities to use the defined profile with no changes. This is perhaps the hardest part, since utilities often prefer to add their own customizations to suit their needs. For this to work, they would have to commit to using it exactly the same way so OEMs do not have to add customizations. For example, SMUD is working on a set of OpenADR profiles specific to their needs, and if a number of other utilities get on board and work with SMUD to adopt the same profiles (or adapt them into something that works for everyone) then this could be a great step forward.

There will always be a trade-off between customizability and interoperability. As load shifting becomes more wide-spread, we should be able to reduce customization and align use cases for more interoperability and lower integration costs. Creating updated program guides and a testing regime that design for cloud VENs and modern load shifting programs, with the backing of major utilities, will be a great next step.