The Challenge of Inter-Protocol Interoperability for Grid Operators and the EV World

The Challenge of Inter-Protocol Interoperability for Grid Operators and the EV World

Recently the California Energy Commission issued a DRAFT SOLICITATION CONCEPT for a series of EV related Interoperability Testing Events.  We support the goal of 100% zero-emission passenger vehicle sales by 2035 and believe that interoperable communications between systems is a critical success factor in achieving that goal. 

QualityLogic submitted comments to the CEC concerning the DRAFT SOLICITATION and we thought a version of those comments would be a valuable addition to GEI.   None of the comments should be considered as a criticism of the CEC.   Solving the problem identified is critical for scaling Grid-EV integration in our view. 

Our focus is on application protocol interoperability – e.g., OpenADR, OCPP, IEEE 2030.5, etc – rather than product standardization.   Product standardization for EVSE’s is certainly a critical area and is foundational to any interoperability standards and testing.  If products don’t do the same functions, communicating in a standard way gets challenging.   Further, a focus on functionality leads to testing that must validate product performance against a standard such as IEEE 1547-2018.   There are efforts in the industry by EPRI (driven by CA IOUs) and UL to create an EVSE functional standard that may or may not include communications interop as part of it.   This is a direction that, in our view, could use some CEC investment.  It is related to but much more complex, both technically and politically, than addressing interoperability of communications between utilities, EV charge networks, EVSEs and EVs.  

EVF Integration Goals

The problem the CEC is addressing is well stated:

For California to achieve its transportation electrification goals…the industry must continue moving towards interoperability, where vehicles, chargers, and software systems work together, without special knowledge or effort by the user. The market is still nascent, and there are several competing standards for hardware and software. Furthermore, new products are rapidly entering the market, posing a challenge for interoperability.

Implied but not explicitly stated is the need for the EV eco-system to interoperate with the distribution utilities (IOUs, MUNIs, etc) which have a major role in the business of decarbonizing the transportation sector.   

California desires to be a leader while establishing a competitive market that drives up scalability, quality and interoperability while driving down costs.   Addressing the Grid-EV interoperability challenge involves multiple concurrent and serial activities.  We attempt to identify some of the key ones below.

Notably missing in the industry is agreement on desired outcomes with associated metrics for assessing success.   Metrics such as the number and kinds of companies to be involved in interop events, the protocols to test and other specific activities does not address how progress towards the goals are measured.   It seems like outcome metrics might include:

• Establishment or acceleration of new test and certification programs specific to the EV domain;
• Number of product certifications generated by the programs;
• Recognition and emulation outside of CA.

The CEC interoperability goals are worthy of millions in investment.   The goals also overlap activities of other organizations.  For instance, the OCA (OCPP ITCA) already conducts their own Interop events 2x per year in pursuit of evolving their standard and interoperability.  What is the value that a CEC funded Interop activity could add to existing industry activities?   Further, unless such activities are done in collaboration with the organizations (SDO/ITCA) responsible improving the standard and certification programs, much of the potential improvements are left to chance and may not occur.

Interop Events

There are a multiple dimensions to interop events in the EV domain:

1. Intra-Protocol Interoperability – Certified Products: testing already conformance certified products with each other that support the same protocol – e.g., OpenADR, OCPP, etc. – to ensure that they work together and identify issues with the protocol and test specifications.   This is typically something done by an Alliance like OpenADR or OCA (or should be done by them).
2. Intra-Protocol Interoperability – Major Standard Update: such activities are used to validate and improve a developing major update to a technical specification – e.g., an update with major new features that require a major update to the certification testing.  Test products would be certified to an existing program but not the update being tested.
3. Inter-Protocol Interoperability: such activities are not that common but would be very useful in environments that require multiple protocols to execute a utility command at the EVSE-EV level.  For instance, a very logical communications channel could be OpenADR to an EV Network system; OCPP to an EV via ISO 15118. The systems in the Interop would all be certified for the protocols they used, given a certification program for them.  The translation points however are not likely to be certified for the translation between protocols so the real value is in testing those translation systems as well as the end-end validation.  Interoperability testing like this is critical but no such formal activities like this exist (that we know of) that could make EV communications interoperability.
4. New Standard Interoperability: if a group is working on a new protocol standard, Interops are a valuable way to discover issues with the standard itself and develop a test specification in the process.

Our perspective is that Interop types 1 and 2 are best left to the ITCAs (Interoperability and Certification Authority – alliances like OpenADR, SunSpec, OCA).  This is a major aspect of their business.  If the CEC or industry wanted to accelerate this type if interoperability testing it could do so by supporting ITCA operated interoperability programs.  The key relevant vendors are already participating in the alliances and it would be the most efficient method to accelerate this form of interoperability activities.

The actual interoperability status for each protocol eco-system is not readily obtained.  There is no standard for assessing eco-system interoperability for a specific protocol and the ITCAs don’t have resources for making such assessments.   A useful, perhaps necessary, activity would be to commission some form of assessment of current intra-protocol interoperability (and perhaps Inter-protocol interoperability) in order to establish an interoperability baseline and identify the most valuable contribution(s) the CEC or others could make towards the EV eco-system interoperability goals.

Interop activities would also be valuable if focused on Interop type 3, inter-protocol interoperability.  This is more challenging and is also key to developing a multi-protocol, interoperable eco-system in CA and beyond.   There is room for innovation in this type of activity and no single organization today focuses on this issue.

Interop type 4 is also an area where the CEC or others could accelerate innovation and standard development.  It is not clear to us what new standards are in development (or could be) but if there are it is a valuable area to accelerate. 

Product and Test Tool Development

This area is another multi-faceted domain.   In our experience, product development activities and test tools associated with Interops include:

1. Finding conformance and interoperability issues with certified products by testing them against other certified products.  This is something that vendors do routinely as part of their participation in an ITCA or other Interop event.  As noted, the ITCAs routinely provide (or should provide) these venues and vendors take advantage of them.   Any events of this nature sponsored by the CEC would achieve similar results but could be redundant or even cause confusion among vendors.
2. Finding issues with new technology (either a major standard upgrade or a developing standard) through Interop events.   Vendors that participate are developing new technology and use Interops to both learn of issues they need to fix and to influence the evolution of the technology standard itself.   Such a focus is most effective if conducted by an organization that can use the results to improve both the standard and a future certification program.
3. Development of test tools for conformance and interoperability testing for existing standards with certification programs.   These tools are typically funded by the ITCAs for the standard or by private vendors in partnership with the ITCAs.  This is the case for OpenADR, OCA and SunSpec (IEEE 2030.5 and SunSpec Modbus).  ISO 15118 is less clear (primarily because we are not involved with it).   In some cases, such tools are developed and supported independent of both an SDO and ITCA for a standard.  
4. Development of test tools for new technology such as a test program for gateway systems converting between protocols or a new standard that is being developed in CA (not sure what that would be).   This is an area that CEC or other funding seems to us to be particularly useful since it is pre-commercial and there is significant market risk for vendors and ITCAs.   

Summary 

For the Grid-EV interoperability challenge, there are significant issues that are not already being addressed by industry and industry alliances.   These include:

1. Intra-Protocol Interoperability Assessment: aimed at providing a baseline for measuring interoperability of an eco-system.  The assessments of the relevant EV protocols could be valuable in further refining the focus of subsequent investments.
2. Inter-Protocol Interoperability: such activities are not that common but would be very useful in environments that require multiple protocols to execute a utility command at the EVSE-EV level.  For instance, a very logical communications channel could be OpenADR to an EV Network system; OCPP to an EV via ISO 15118.
3. New Standard Interoperability: if a group is working on a new protocol standard, Interops are valuable as a way to discover issues with the standard itself and develop a test specification in the process.
4. Development of test tools for new technology such as a test program for gateway systems converting between protocols or a new standard that is being developed in CA (not sure what that would be).

The area of standardization of EVSE functionality is also a critical area of focus but we’ll leave that to another article.