Creating DER Integration Solution Architectures Using IEEE 2030.5 and the EnergyIoT Common Reference Model

Posted to GridIntellect, LLC – A Veteran-owned Company in the Digital Utility Group
image credit: Stuart McCafferty
Stuart McCafferty's picture
Lead Architect, eaaS Siemens Smart Infrastructure CTO

2021 Cleanie Award winner. Siemens Smart Infrastructure CTO Office, technologist, distributed energy expert, researcher, author, and climate change warrior. Genuinely focused on doing good for...

  • Member since 2018
  • 112 items added with 103,821 views
  • Apr 7, 2021

Figure 1:  The EnergyIoT Common Reference Model


By Stuart McCafferty

California has it right!  In 2019, the California Public Utilities Commission (CPUC) created the “Rule 21” mandate for integrating behind the meter Distributed Energy Resources (DER).  This was primarily directed at rooftop solar that is being installed at record pace and is now a lawful requirement for all new construction.  The ruling requires that all inverters connected to the grid must comply with IEEE 1547 interconnect requirements and one of three communications protocols:

  • IEEE 2030.5
  • SunSpec Modbus
  • DNP3

Why?  Plain and simple it is for one thing:  INTEROPERABILITY!  The CPUC created these requirements because:

  1. The state of California is committed to decarbonization and recognizes that a large number of new stakeholders, IoT assets, and intermittent generation and unanticipated loads will be key problems to tackle in order to be successful.
  2. DERs must increase resilience while maintaining current safety and reliability requirements
  3. Non utility owned DERs will need to support utilities and grid stability by providing grid services individually or through aggregation.
  4. New stakeholders are welcome and will be allowed to participate in utility grid services through customer programs and could also potentially participate in wholesale and local markets.
  5. Costs for integrating DERs into utility operations and markets must be simplified and relatively inexpensive to implement.

The CPUC recognized that having a small set of communications protocols and information models would help them achieve their aspiration of an interoperable grid that supports democratic participation and a decarbonized electricity ecosystem.

Why IEEE 2030.5?

2030.5 was previously named the Smart Energy Profile (SEP) and was developed by the Zigbee Alliance as a metering communication solution primarily to coordinate with behind the meter building energy devices.  It was adopted and ratified by IEEE and is now on Version 2.  But, the standard has been around since 2009 and has evolved to a very rich standard and a growing ecosystem supporting testing and certification for interoperability and security compliance.  It is one of the few true “energy IoT” standards developed for modern grid communications, distributed intelligence, and interoperability.  OpenFMB™ is another IoT standard that also has incredible implications to support a nimble and neural grid as it matures.

IEEE 2030.5 is based on the Common Information Model (CIM) that was developed by the International Electrotechnical Commission (IEC) standards organization.  If it is not immediately obvious, this is a really good thing!  It leverages an international information model that makes interoperability more likely and achievable – something the electric power industry has really struggled with.  The other really great thing about this is that it is message-based communication, not the register-based old-style communications where centralized SCADA systems flip bits on grid assets to control their behavior.  This old style of command and control requires register mapping and is prone to mistakes that are difficult to troubleshoot and correct when things go wrong.  Nowadays, most grid assets are intelligent and instead of controlling them, centralized and localized grid management systems can tell the asset what they want it to do instead of doing it to them.  If something does go wrong, then it is easy to troubleshoot by checking to see if the correct message was sent, if it was received, and how the asset behaved when the message arrived.  Easy peasy.

The 2030.5 standard was designed for aggregation and hierarchical coordination, supporting a wide range of IoT use cases, and especially for Distributed Energy Resource (DER) visibility, situational awareness, and coordination.  So, new requirements such as FERC 2222 that necessitate that Transmission System Operators (TSOs) provide DER aggregators with market participation opportunities are inherently cooked into the architecture using physical “gateways” to aggregate DERs and that can even aggregate other gateways in parent-child hierarchical relationships.

Figure 2:  Hierarchical coordination of DER using IEEE 2030.5 standard architecture

Mapping IEEE 2030.5 to the EnergyIoT Reference Architecture

The IEEE 2030.5 standard also maps rather neatly with our EnergyIoT Reference Model and is the enabling technology that helps our common reference architecture develop REAL solution architectures.  Therefore, over the past couple of months, we have been doing exactly that in-between projects and trying to help our industry think beyond point solutions and to “think IoT” when developing architectures.  We hope to leverage modern standards and a common reference architecture to develop more interoperable solutions, create a greener grid, support more DER use cases, increase grid resilience, and create new opportunities for innovation and participation.

Figure 3:  Mapping IEEE 2030.5 to the EnergyIoT Reference Architecture

The above image shows the relationship of the 3 IEEE 2030.5 layers to the 3 logical layers of the EnergyIoT Reference Architecture.

  • Utility Server:  The 2030.5 utility server is located in the Energy Business Systems domain.  It communicates with other utility business systems to provide information such as visibility, situational awareness, and available capacities.  Queries, negotiation, and dispatch of aggregated DER can be performed by the utility by communicating via the publication/subscribe (pub/sub) MQTT protocol with the Energy Services Cloud based IEEE 2030.5 aggregator.  The naming of “Utility Server” is not exactly accurate, however, since the utility server could be used by a Distribution System Operator, a company managing a large number of DERs (or EV chargers or microgrids) to coordinate and optimize for economic or other business reasons.
  • Aggregator (VPP):  The 2030.5 aggregator resides in the Energy Services Cloud providing aggregation and abstraction capabilities.  It acts as a Virtual Power Plant (VPP) coordinating capacity across numerous DERs.  Because communication between the utility server and (optionally) the API gateway uses the MQTT pub/sub protocol, there is no client/server relationship and communications are event-driven with no need for clients to “check in” with the server to look for new messages.  Pub/sub works much simpler and more securely when there is a homogenous network and the public internet is not part of the topology.

The aggregator is really the intelligent piece of the 2030.5 architecture.  It monitors all of the gateway assets, groups them into logical units, manages the DER system of record, updates the available capacities, and provides dispatch schedules to the gateways based on the utility server’s requests.  It also monitors dispatch events and collects behavior and performance information to support analytics and other metrics.  The Australian company, SwitchDin, includes a DER registry “system of record” that can be leveraged by the utility to support grid planning and even grid connectivity and power flow models.

  • API Gateway:  The 2030.5 gateway is the abstraction to the Operational Technology (OT) physical layer.  It is the working class device of the 2030.5 architecture.  It does a lot of cool things. 
  1. It aggregates any DER it can communicate with within its control horizon. 
  3. It acts as a “universal translator”, translating IEEE 2030.5 messages into native DER protocols such as modbus, DNP3, CAN bus, IEC 61850, etc. and can be programmed to speak to proprietary vendor protocols such as NEST and ECOBEE. 
  4. Additional capabilities can be remotely installed by the IEEE 2030.5 Aggregator using containers and orchestration.  As an example, SwitchDin, includes an Energy Management System (EMS) option for residential and business owners to allow that customer to manage the DER assets on their premises.
  5. Gateways can aggregate other gateways.  What this means is that there is a lot of flexibility in system designs and can be layered in a hierarchical architecture.  SwitchDin is actually using their gateways as a simple microgrid controller and has two types of gateways – one for customer and business premises and another for utilities and Transmission System Operators to place at critical service locations such as key circuits, feeders, distribution substations, and T-D substations.  Think about FERC 2222 and how the SwitchDin solution could solve the Independent System Operator (ISO) issues around DER aggregator participation.  Those capabilities already exist.
  6. Did we mention that the gateway can discover other 2030.5 assets?  Oh yeah, we did.  But, worth mentioning again just so you don’t forget!  Dynamic plug-and-play possibilities.

So in summary, the architecture of IEEE 2030.5 is an IoT methodology consistent with the EnergyIoT Reference Model where:

  • The Utility Server maps to the EnergyIoT Business Services layer.  It could reside on premise at utility or in the cloud.
  • The Aggregator maps to the Energy Services layer providing aggregation and abstraction.  It resides in the cloud.
  • The API Gateway maps to the Operational Technology (OT) Physical Systems layer.  It resides at the “edge”.

The EnergyIoT Reference Architecture is freely available on Energy Central with the same intent of the IEEE 2030.5 standard to create interoperable solution architectures from the customer to the utility and the TSO.

Enhancements to the EnergyIoT Reference Architecture

We developed the EnergyIoT Reference Architecture in late 2018 and published it on Energy Central in the first quarter of 2019 as a series.  Since then, we have made a couple of enhancements and we might need to retouch the published series – but we haven’t done that yet.  However, here are the changes we have made in case you decide you are interested in reviewing the EnergyIoT articles and notice some differences:

  1. Workflow Automation – Within the Energy Services Cloud, we had an architectural element called “orchestration”.  In Article 6 of the series, we described the idea of workflow and used Node Red as an example of how to orchestrate the workflow.  But, orchestration has another meaning in the IoT world in how containers are managed using tools such as Kubernetes.  So, we renamed Orchestration to Workflow Automation.
  2. Aggregators and Community Choice – We originally had this element in the OT layer.  That was clearly a mistake.  We have moved that element into the Energy Services Cloud layer where it belongs.
  3. Gateways and Controllers – We had always assumed that these types of OT assets were there to simplify and abstract communications with other physical assets, but we did not specifically call them out in the original architecture.  That has now been rectified and they are called out in the OT Physical Systems layer of the architecture.
  4. Carbon Markets – In the original architecture series, we discussed the concept of future carbon markets.  We have added that as a sub-element of the Market element in the Energy Business Systems layer.

Figure 4:  Changes to EnergyIoT Reference Model Made Since April 2019

Other than that, there are no other changes, but if you see something that you feel is missing, please provide a comment below.

Going Forward

Lately, Stuart, Eamonn, and David have been developing solution architectures for wind farms, microgrid fleets, behind the meter customer DER (connected communities), and EV fleet charging with the intent of integrating them with utility operations and markets.  We use the EnergyIoT Reference Model as the starting point and map the IEEE 2030.5 architecture to the affected architectural elements.  It doesn’t address all of the potential electric power grid use cases, but it has really helped us to recognize the different business systems, energy services, and OT assets that need to be addressed within each DER use case architecture.  The whole point of this simple exercise is to easily communicate what can be some fairly complex relationships in an architectural drawing that people at all levels of an organization can understand.

As an example, this is a simple layered architecture view we developed for EV fleet charging that uses the IEEE 2030.5 standard:

Figure 5:  EV Charging Solution Architecture Mapping IEEE 2030.5 to the EnergyIoT Reference Model

You will quickly recognize the key architectural layers for both the EnergyIoT Reference model and the mapping to the 2030.5 layers.  There are obviously other architectural drawings that are needed, but this simple architectural depiction is a good start if you are working with a variety of different stakeholders showing the use of this very important DER integration standard.

We have educated ourselves on IEEE 2030.5 and have also been working with the SwitchDin folks Down Under where they have been applying a very similar methodology for a variety of DER integration use cases.  There are some excellent resources available for anyone interested in learning more about this standard:

IEEE 2030.5 answers many of the issues surrounding DER integration – for grid services, markets, and even EV charging.  The CPUC should be commended for their foresight in establishing IEEE 2030.5 as one of California's required standards for grid-connected inverters and it would be smart for other state PUCs to consider following their lead.  This will help drive the vendor community to quickly adapt and build DER assets that are as close to plug-and-play ready as they can be.  For us to truly capture the value of connected DERs, they must interoperate with utility systems to support grid services and market participation.  IEEE 2030.5 is definitely a step in the right direction that embraces the concept of distributed intelligence, the Internet of Things, and uses modern messaging communication protocols.

We are happy to make introductions to any of the companies discussed in the article - contact Stuart.  DER solutions are available today, and the EnergyIoT Reference Model and IEEE 2030.5 protocol are excellent resources to help you get started with your own disruptive solutions.


Download free DER Solution Architecture PowerPoint Template


No discussions yet. Start a discussion below.

Stuart McCafferty's picture
Thank Stuart for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member

Get Published - Build a Following

The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »