OpenADR and Coincident Peak Pricing are a Good Match

How OpenADR should be used alongside peak forecasting to help customers automate their load shifting in coincident peak pricing programs.

8 minute read ∙ May 18th, 2020

Now that OpenADR has been implemented by many commercial and industrial building automation systems, lighting controls and HVAC systems, it opens up more potential use cases for the protocol, such as Coincident peak pricing.

Coincident peak pricing is an often-used component to a utility bill for larger customers, in which the customer is charged for their total consumption during just the few hours of the year that coincide with the overall utility peak. Since it can't be known until the full measurement period is over (i.e. the month, season or the year) when exactly the peak occured, forecasting or estimating the peaks and reducing consumption accordingly is a critical skill to reducing utility bills in these markets.

Many utilities and grid operators use this pricing regime to encourage more efficient use of the grid. Two major examples, among many across the world, are ERCOT's 4-CP charges, based on the top 15-minute interval for each month from June through September, and Ontario's ICI program, based on the top 5 hours of the year. There is a wide range of pricing: coincident peak charges are most typically around $20 / kW / year across the country (on top of regular electricity charges), but in Ontario's program it is more than 10 times that. Many participants in these programs have a peak load of >10,000kW, so the stakes can run into hundreds of thousands or even millions of dollars per year.

There are a number of companies that support businesses in these regions by providing forecasts of when the peak will occur. Currently these companies differentiate themselves on who has the most accurate forecast. But for many, the differentiation ends there, as they email, phone or text their customers to tell them to curtail load manually. A better way to differentiate will be helping their customers automate their response, so their building or facility will automatically reduce load based on expected peaks.

When they are very confident it will be a peak hour, automation lowers the burden and risk for the operator. When there is a chance of a peak but not a certainty, the customer's building can lower consumption accordingly without causing a major event. Some forecasting companies already offer a proprietary API that their customers can integrate into to get the information on a regular basis. To reduce integration costs and improve interoperability, they should use OpenADR.

OpenADR is currently the go-to standard for load shifting on the grid, used throughout North America and, increasingly, the world. For more on OpenADR and how it works, see our overview of the protocol. Since many building management systems are already using OpenADR to help their customers shift load, they are ready to connect into an OpenADR signal and respond accordingly with lower integration cost than a proprietary API.

So, how would this work?

Implementing OpenADR for Coincident Peak Forecasters

In OpenADR, the party sending the signals (in this case the forecasting company) operates a Virtual Top Node (VTN) and the party receiving the signals (the buildings) is operating a Virtual End Node (VEN).

The forecasting company would program their VTN to send out OpenADR signals that correspond to forecasted system peaks (more on that later). This could be done manually through a UI, or programatically through an API connected to the forecasting system. It would convey the information to all of the VENs and the buildings would automatically shift their load accordingly.

The best two options for buildings to receive OpenADR signals are using a cloud-based VEN attached to their building management system, or using a physical VEN on-site at each building. For each building customers, the model that makes the most sense depends primarily on the sophistication of their building management system.

Cloud VEN model

Many Building Management Systems are already OpenADR certified and capable of connecting to a Virtual Top Node (VTN) and receiving an OpenADR signal. In this case, the Building Management System provider would program a single VEN, hosted in their software architecture, to connect to the VTN. The following diagram shows how it would work:

• The forecasting company programs their VTN to send a forecast to VENs
• The VEN passes the signal to the building management system
• The building management system controls the end loads at buildings that are registered with the program

Physical VEN model

For companies that do not have sophisticated Building Management Systems with a built in OpenADR VEN, they can install a hardware device on site (such as the Universal Devices ISY994 PRO OADR) that fully implements a VEN and has a programmable interface to send that signal through to the building management system to shift load accordingly.

The implementation model would ultimately be similar to the cloud VEN. The main difference is each building would have a VEN on-site, as the following diagram shows:

In this case, the building energy manager would most likely program the VEN, with guidance from the forecasting company.

What would a forecast look like?

OpenADR has a concept of discrete Events as well as Event intervals.

A blunt way to implement would be to make each time period (e.g. hour of the day) a discrete event that reflects how the building should react to a possible peak. For example:

A more refined way to do this would be to use Event intervals to decrease the communication necessary, so there could be one event for each day and multiple intervals as needed. For example:

An even further refinement could be to assume that, given the vast majority of hours will be "No Peak", the lack of an event means business as usual. Then the event would become:

The best way to implement would be based on how much information the forecasting company wants to share.

So, how would we represent these different states in OpenADR?

Event Types

OpenADR has a number of different event types, so there are a few options for how this could be implemented.

Simple event type

The simplest event type in OpenADR is appropriately named Simple. This allows a payload of 0, 1, 2 or 3. This would be a very simple way of representing forecasts. For example, the payloads could be matched to a pre-programmed controls regime in the building controls system:

As described above, 0 would not need to be sent by default but could be used to override a prior event, for example by overriding a possible peak with a no peak.

Demand charge event type

Some forecasters prefer to provide a probability of peak for each hour of the year, which would be more complicated. OpenADR provides a number of fields that allow a decimal payload to be sent, that could represent a value from 0 - 100 with the % chance of a peak for any given hour. None of the event names are a perfect fit to describe peak forecasting, but the DEMAND_CHARGE signal fits pretty closely. It has a paired, unitless value called priceMultiplier that may be used to send a decimal value every hour. VENs would need to be programmed to respond appropriately to the decimal value they receive.

Custom event types

A more idiosyncratic way to convey a forecast probability would be to create a custom event type. OpenADR allows for this and defines a convention where a custom event type will be preceded with x-. The VTN could create an event called x-peakProbability, and define it for the VENs so they could configure their response appropriately. The main drawback with custom event types is that VENs will have to be specially configured to accept them.

Beyond peak forecasting

For companies that are providing more than just peak coincident forecasting, OpenADR can help. OpenADR allows for a number of different, overlapping signals that refer to the same time period. For example, for an hour time period multiple signals could be sent:

• Forecasted price of electricity, using the ELECTRICITY_PRICE event type
• Probability of a peak load event during that hour, using a custom event type
• Guidance on how much the customer should shift, using a SIMPLE event type

That way, the customer can either integrate the price and peak probability to custom code their response, or if they want to keep it simple they can just use the SIMPLE event and follow your guidance. The important thing, as with any API, is clear documentation to VENs of what to expect, and what to do with that information, so they can seamlessly integrate.

Registration / Security

Of course, companies can't just let anyone connect to their VTN and get access their valuable forecasts! A VTN will not connect with a VEN unless it has been pre-configured, and for added security uses TLS certificates. OpenADR by default uses Kyrio as the certificate authority, so you can validate VENs that connect to the VTN. VTNs may decide to use a different CA or act as their own, if they prefer.

That's pretty much it! Forecasting is a relatively simple implementation of OpenADR because it only requires one-way information flow, so complexities around VENs reporting and opting in/out of events do not apply. It does need to be stable, predictable, and interoperable, and OpenADR provides that well.

How to get started

For forecasting companies that would like to move into automation, or those that are already providing an API but would like to try out OpenADR, please contact us. We'd be happy to help you set up a low cost pilot and get started on your OpenADR journey. We can either work with one of your existing customers to work as the VEN, or help you find a VEN owner who would be interested in trying it out.