DERMS 101: Intro to Integrations

The primary purposes of demand flexibility programs are to shift load to off-peak hours and mitigate high energy costs. To do this effectively, program managers need a distributed energy resource management system (DERMS), context with which to make decisions about upcoming load shift events, and a pool of distributed energy resources (DERs) to respond to those events. Successful programs strategically manage enrollment using incentives to increase the load the program can shift.

Integrations power every one of these actions.

All VPP and DERMS software offerings are inherently platforms: technologies that interact with other software and hardware. These platforms interact daily with a wide range of software systems, such as CRMs, rate databases, operations software, and hardware systems, including—indirectly—all of the DERs they manage.

Each one of these interactions happens through an integration between the VPP or DERMS platform and the other system. Integrations exchange pre-determined kinds of data and information between the two systems at specific times, either on a set schedule or when an action, such as an enrollment, triggers a data exchange. When building the integration, the two partners specify which kinds of data can be exchanged, and they develop the integration around that specification, whether the integration is based on APIs, OpenADR, or other protocols.

Device

Device integrations, also known as device partner integrations or OEM integrations, are integrations with the distributed energy resources that make DER management possible. Device integrations are a fundamental part of the DER platform; without devices to control, the DERMS cannot shift any load. These integrations are built in collaboration between the DERMS vendor and the device manufacturers, who both must build support for the integration.

Device integrations typically have three components:

• Enrollment: The device partner must be able to receive a signal from the DERMS that a homeowner has enrolled in (or unenrolled from) a program and make that device available to the program. Some device partners also support in-app enrollment, where the flow is reversed, and the device partner sends a signal to the DERMS that a homeowner has enrolled in the program.
• Control: The device partner must be able to receive a signal from the DERMS that a control event has been requested. This command typically includes a mode and/or a setpoint, such as a command for a battery to Discharge or a command for a thermostat to reduce its temperature by 2 degrees.
• Telemetry: the device partner sends near-real-time data to the DERMS, which is used to monitor devices and their participation in events. This data can include continuous signals, such as thermostat temperature or battery state of charge, and discrete signals that change less frequently, such as the device mode or battery backup reserve value (minimum allowable state of charge).

Data Ingestion

Data Ingestion integrations are integrations with data sources that are inputs to the DERMS software and the decision-making processes of the DERMS users. This data is used by core features of the DERMS platform that would stop working without it.

The most common types of data used by Data Ingestion integrations are:

• Demand Data: Some DERMS platforms can read demand data from the system as a whole or from individual sites. This data could be used as an input to forecasting models or it could be presented directly to the DERMS platform users for context when planning events.
• Energy Rates: Some DERMS platforms can use retail and wholesale rate data as an input to optimizations. This data could be used as an input to forecasting models or energy arbitrage optimization, or it could be presented directly to the DERMS platform users for context when planning events.
• Weather: Some DERMS platforms can use weather data as an input to forecasting models. Because weather affects the use of climate-control devices (e.g., HVAC) and the generation of solar and wind energy, it can be used to improve the accuracy of models for forecasting data such as system load.

Operations Software

Integrations with operations software support simple workflows by allowing users to conduct some operations of the DERMS platform from other systems that they use regularly. This strategy fits into users’ existing processes and benefits from that context while leveraging the power of the DERMS platform.

Integrations with operations software could be used for processes such as:

• Enrollment Management: Homeowners can enroll in a program through the customer’s existing CIS, CRM, or similar system, which builds trust in the program. The utility can review and approve or deny each application in the context of that system.

• Event Calling: Utilities can schedule events in the context of other data relevant to the decision, such as system load, day-ahead pricing, or events across multiple member co-ops.
• Homeowner Messaging: Utilities can send messaging, such as enrollment approvals and event notifications, through a communication system that homeowners are already familiar with.

DERMS 101: Intro to Integrations Conclusion

Energy demand is on the rise, driven by AI and data center growth, supply chain challenges, electrification efforts, and the impacts of climate change-induced severe weather patterns.

Load shifting programs like demand response, EV charging, and virtual power plants have proven effective in conserving energy during peak periods of demand, defraying high peak energy costs, and enhancing grid resiliency. Still, these programs are complicated by variables, including the device, device type, and more.

Like the U.S. grid, integrations need to be flexible and resilient to adapt as program requirements change and technology improves, which provides a robust, comprehensive suite of integrations that enable an easy and efficient means of scaling programs, adding new devices, and pivoting tactics to different demand flexibility program types as needed.

About The Author

Katarina is the API Product Manager at Virtual Peaker, where she guides the strategy and development of Virtual Peaker's APIs and integrations by applying nearly a decade of experience managing near-real-time streaming data platforms. Katarina joined Virtual Peaker to put her background in manufacturing, data science, and engineering to work addressing the climate crisis. In her free time, she puts her interest in resilience and conservation to good use supporting endangered and threatened species in her local ecosystem, even if her neighbors think they look like weeds.

More About Katarina