IEEE 2030.5 Takes Off: The Latest News on the IEEE 2030.5 Standard

It is wonderful to look back at the blog we wrote in November of 2017 and see the amazing progress the IEEE 2030.5 community has made in the past 2+ years. Since then:

• We’ve gone from waiting for CA Rule 21 to have a “required by” date to having such a date (June 22, 2020) and driving the vendor community to invest in IEEE 2030.5 development and certification.
• We’ve gone from a concept of a test and certification program for IEEE 2030.5 for DER to having a complete program organized and managed by the SunSpec Alliance (see https://sunspec.org/sunspec-certification/). This is a huge leap forward.
• We’ve gone from beating the bushes for companies and researchers working on IEEE 2030.5 to working with the 8 SunSpec approved test labs and dozens of vendors implementing IEEE 2030.5.
• There is now an open source implementation of an IEEE 2030.5 Client available free on EPRI’s Github site.
• We’ve seen utilities outside of CA in the US, Canada and Australia requiring IEEE 2030.5 for both DR and DER applications.

Two years ago, QualityLogic organized the “2nd IEEE Symposium and Expo and a public workshop” in Southern CA. We had about 80 attendees for the two-day event. SunSpec has now conducted at least 4 public executive workshops in the past year and created an online education course through UCSD.  QualityLogic is a sponsor of both activities and participates in them.

This blog aims to dive into the progress of the IEEE 2030.5 standard on the following topics:

1. The complexity of implementing IEEE 2030.5 and how QualityLogic is helping to simplify the process
2. How a strong alliance of utilities and vendors are building an IEEE 2030.5 eco-system
3. The importance of IEEE 1547.1 in managing DER assets
4. IEEE 1547.1 certification and the “end-end” testing challenge
5. What is next for IEEE 2030.5

Implementing IEEE 2030.5 is Not Simple

IEEE 2030.5 is a very rich, modern IOT protocol. It has over 30 distinct “function sets” covering everything from device discovery to security to smart grid functions like DER, demand response and flow reservation for EVs.  

Even implementing an application as narrowly defined as the Common Smart Inverter Profile (CSIP) is more complex than you would imagine. All that is needed is to implement the DER specific function set in IEEE 2030.5. Correct?

Not so. The structure of IEEE 2030.5 requires implementation of almost 20 of the 30+ function sets to be compliant with the CSIP requirements. These include everything from discovering device to device capability exchanges to both polling and pub/sub communications and much more. This is the reason that QualityLogic has been so busy training both the development teams and test labs.  We’ve even given our two-day workshop to utilities wanting to better understand what they should be asking vendors for.

Building a Standards Eco-System is Not Easy

The progress made with the IEEE 2030.5 standard is rather amazing, especially given the lack of a well-organized and funded alliance for the standard. Where is the equivalent of the Wi-Fi or Zigbee or OpenADR or the MultiSpeak Alliance for IEEE 2030.5? There isn’t one and that is a long-term issue.

Fortunately, the SunSpec Alliance took on the task of creating and managing a certification program for the application of IEEE 2030.5 to DER management. And the IEEE 2030.5 work group continues to evolve the standard. Just recently, the work group started work on the next revision having just finished the 2018 version. A group of vendors led by Hydro-Ottowa are engaged in using IEEE 2030.5 for the Great-DR project. And two utilities in Australia are working on implementing their own version of IEEE 2030.5 DER management.

We tried in 2016 to create an alliance around IEEE 2030.5 but at that time there was not quite enough interest. NOW THERE IS and a group convened by the DoE and IEEE is assessing what is most needed for the future of the standard. The answer I see emerging is a strong alliance of utilities and vendors with investment in the IEEE 2030.5 standard.   

How that will evolve is TBD. But if you are interested in making it happen, please contact us so we can get you involved when we have a clear direction.

What is IEEE 1547.1 and Who Cares?

IEEE 1547 is the industry standard of IEEE for managing the interconnection of any generating resource to a distribution grid. The standard has just been updated in 2018 to incorporate smart inverter functions. Prior to this, the standard was very simple and basically required the inverter for the generation source to disconnect from the grid under any anomalous circumstances. If the local grid suffers a voltage sag or high-voltage “blip”, the inverter was required to stop putting energy into the grid. The goal was to ensure that distributed energy resources (DER) did not damage the grid under stress conditions.

The IEEE 1547-2018 version ensures that DER resources can be used to manage grid reliability. For instance, instead of disconnecting from the grid when the voltage sags, smart inverters could be asked to provide voltage support to the local grid.  

IEEE 1547.1 is the companion standard to IEEE 1547 that specifies how to conduct the tests that certify IEEE 1547 compliance. IEEE 1547.1 is primarily a functionality test for advanced smart inverter functions.   But IEEE 1547-2018 also adds for the first time a required communications capability using one of three designated protocols:

• SunSpec Modbus
• DNP3
• IEEE 2030.5

And IEEE 1547.1 specifies how to test for the communications capabilities. This is a huge step forward in that for the first time a smart inverter hardware certification program will validate that sending instructions or information in an industry standard protocol will achieve the desired behavior of the system. The significance of this for managing DER assets cannot be over-emphasized. It is a great starting point for gaining confidence in the interoperability AND performance of a smart inverter in a single certification program.

The End-End Validation Challenge and IEEE 1547

One of the major issues in CA Rule 21 today is how to ensure that instructions sent from a utility DERMS to an aggregator or building EMS are turned into the intended behaviors of the targeted smart inverters. Some stakeholders seem to believe that full end-to-end testing will be conducted with IEEE 1547.1.    

Unfortunately, IEEE 1547.1 certification testing will not accomplish the objective of a full end-to-end test. IEEE 1547.1 actually does the following for interoperability:

• It ensures that one of three standard protocols (DNP3, SunSpec Modbus or IEEE 2030.5) can be used to communicate the inverter function settings defined in IEEE 1547-2018 to a local inverter control system or gateway device. 
• Validates that the communicated functional instructions are correctly implemented in the smart inverter.

The use of the term “gateway” in IEEE 1547-2018 means a local communications capability. And it must be in physical proximity to the actual inverter system (rather than cloud-based). The purpose of defining a gateway as a local interface is to reduce the risk of a communications failure due to the loss of the cloud or an internet connection.   

The hope that IEEE 1547.1 will address the end-end testing issue is misplaced.  What IEEE 1547.1 will not do is the following:

• IEEE 1547.1 will not require that one of the standard protocols is used in the installation and operation of an inverter.  While IEEE 1547.1 ensures a “capability” to use one of the protocols, the requirement to actually use it will be a vendor, utility or policy specific decision.
• It does not ensure that the local interface for IEEE 1547.1 testing will be IEEE 2030.5. That will be up to the inverter vendor. If they already have a SunSpec or DNP3 local interface, that may well be the protocol used for IEEE 1547.1 certification.
• There is no “end-end” testing in IEEE 1547.1. The certification only validates that a correct message in one of the protocols from a simulated aggregator, utility, cloud-based adapter, EMS, etc., will result in the desired performance. There is no testing with a specific EMS, aggregator system, utility DERMS, or any other source that may be sending real instructions to the inverter.
• The IEEE 1547.1 Interoperability test is not a protocol test. While it ensures that the IEEE 1547 functions can be managed via a specific protocol (including monitoring and scheduling), it does not validate that the rest of the protocol is functioning correctly.  That is what is done in a protocol test such as the SunSpec IEEE 2030.5 CSIP test.  This means that an inverter can pass a 1547.1 interoperability test but still not communicate correctly with a production server for that protocol.
• IEEE 1547.1 does not include any security testing to validate certificates, authentication and security features and controls.  This is a critical aspect of an end-end test in our view.

The bottom line is that the IEEE 1547.1 certification will not solve the “end-end” testing challenge. 

What’s Next for IEEE 2030.5?

Progress in implementing IEEE 2030.5 is being rapidly made in California and other utilities are developing similar programs. DERMS, aggregator, building EMS, microgrid control systems, gateways and inverter controllers are all incorporating IEEE 2030.5 and a robust DER protocol test and certification program is finally in place and operating. There are 8 authorized test labs, a security infrastructure, commercial and open source code bases and a set of test and certification tools to assist the development of IEEE 2030.5 systems. 

As CA Rule 21 comes into effect and the industry observes that an IEEE 2030.5 communications infrastructure can fulfill its promise, other utilities and jurisdictions will follow.

What is needed most now is a robust industry alliance aimed at educating and implementing the IEEE 2030.5 technology globally.

Contact us today.