Proceedings of the Grid 3.0 Interoperability Workshop

Proceedings of the Grid 3.0 Interoperability Workshop

December 8-9, Tulsa Oklahoma

DRAFT - Version 1.01

1/11/2016

Table of Contents

Introduction 3

Grid 3.0 Context for the Workshop 3

Workshop Agenda: 4

Characterization of the State of Interoperability 5

Key Actor List 7

Interoperability Cost/Benefit Discussion 7

Procurement Issues 8

Interoperability Information Repositories 9

Workforce Skills 10

Accelerating Deployment of Interoperable Systems 10

Standards Gaps 10

Issue Discussion Recap, Observations and Actions 11

Organizational Activity and Capability Matrix Review 13

Grid 3.0 Role and Task Analysis 14

Task Summary 15

Task Priority Scoring 16

Next Steps 16

Diagrams References in Workshop 17

Introduction

These proceedings are a modestly formatted version of the raw notes captured during the workshop that preserves most of the thoughts expressed that lead to the final list of tasks and priorities that are the primary outcome /deliverable of the workshop.

Grid 3.0 Context for the Workshop

Nine Organizations Come Together to Promote Coordination and Collaboration to Achieve the Vision of Grid 3.0

The U.S. Department of Energy (DOE), National Institute of Standards and Technology (NIST), National Electric Manufacturers Association (NEMA), Smart Grid Interoperability Panel (SGIP), GridWise Architecture Council (GWAC), UCA International User’s Group (UCA), the Institute of Electric and Electronic Engineers IEEE), GridWise Alliance and the Electric Power Research Institute (EPRI) have joined together in an informal, ad hoc collaboration to engage stakeholders and develop a roadmap to identify the critical activities needed to achieve the resilient, flexible and highly-interactive grid of the future – Grid 3.0. The motivation for collaborating on this roadmap is to promote coordination and collaboration across organizations to most efficiently perform the research and development needed to achieve Grid 3.0.

Grid 3.0 Future States

·  Based on previous workshops, 12 aspirational “future states” have been identified that collectively describe Grid 3.0.

·  One of the highest priority future states is:

o  Well defined points of interoperability characterized by agreed upon standards exist and are utilized by all electric sector stakeholders

·  The most recent workshop at NIST identified a series of issues related to interoperability that should be addressed

·  The following slides break these down into business/process/people issues and technical related issues

Interoperability Issues and Needs Expressed

·  Define where points of interoperability should be

·  Need references to qualitative benefit and cost assessments in transitioning to standards based interoperable products

·  Need reference content for inclusion of specific IT/OT standards in procurement artifacts

·  Need references to technologies using industry standards for interoperability

·  Need references to projects using industry standards for technology interoperability

·  Need catalog of reference implementation technical designs using industry standards

·  Need references to best practices for how-to transition to standards based interoperable products

·  Need access to use cases in which industry standards are being used

·  Need references to vendor and stakeholder successes in adopting standards in products

·  Need more agile and available resources for develop of new information models for new device classes, business models and applications

·  Accelerate the refinement and deploy ability of key standards such as the IEC CIM and 61850

·  Need reference implementations for specific standards

·  Develop new standards for new device classes, business models and applications

·  Need more test/certification processes for existing standards

·  Need catalogs of test cases (freely available, maintained, for specific implementations)

·  Need cross group(s) collaboration to focus on key items noted above including:

o  value statement asks

o  collecting applicable use cases

o  identifying agile/available resources to address architecture and standards development asks

o  identifying reference implementations, technical designs that use industry standards

o  test-certification asks

o  identify best practices for how-to transition to standards based interoperable products

Workshop Agenda:

Characterization of the State of Interoperability

After more than ten years of industry focus on interoperability, a large segment of stakeholders are still willing to live with non-interoperable systems that are characterized by proprietary, non-standards based integrations and/or single vendor solutions.

This is challenging because in todays world with more devices and more automation, the need for interoperability is greater than ever.

A lot of interoperability activity has been focused at low levels of the GWAC stack. Today’s reality (pervasive distributed resources, new utility business models, new markets) is forcing us to move the discussion of interoperability to higher levels of the stack – specifically in those layers where regulatory and business processes are defined.

If we look at other parts of the world we see that standards based interoperability is often forced by law and regulation. We have different drivers in the US. Utilities and states don’t simply follow the lead of others. These entities need to develop their own business case.

Another change underway is the role of vendors. In the past a single vendor would often be given the lead and handle full implementation and integration of a utility project. With the advent of new technologies, pervasive communication, the internet of things and other innovations, single vendors are not dominating the solution landscape as much as they once did. There is an increasing stake in interoperability if more vendors are going to fit seamlessly into a larger system. Even with standards based points of interoperability, system integration costs are often higher than the software and system hardware cost. This indicates that we can’t completely lose sight of the lower levels of the GWAC stack. A holistic view is required and must be balanced with the business case.

Issue: It is important for any organization to evaluate the impact of interoperability or the lack thereof on all processes.

Another challenge in building a culture of interoperable systems is the need for common language for systems, data, applications and technology. New ways of visualizing systems through reference models and other means such as infographics is needed to move toward a common understanding of the problem.

Organizations such as NIST and SGAM have developed graphical depictions and reference models to facilitate framing the problem but interpretation of these models is still challenging.

Other issues identified in the workshop include:

·  Addressing cyber security gaps with respect to business function interoperability.

·  Funding to promote, test, and evaluate interoperable solutions

·  Finding incentives and educational collateral to get entities to use/follow interoperability concepts

A barrier to implementing interoperable solutions is perceptions on the cost of interoperability. It was noted that a lack of interoperability stifles innovation. In the utility world for example, very narrow, slow to change rules often limit the ability to innovate even if the organization has the capability to do so. Strict adoption of IEEE 1547 in state regulations is an illustrative example of such a rule preventing innovation in the use of DER to support enhanced system reliability through islanded system operation. New rules, regulation and laws need to allow for innovation in the face of rapid technology change.

Issue: Regulatory engagement in interoperability. What do we need to do to improve interaction with regulators and policy makers? In the past we have seen the use of regulator and decision maker checklists. This points again to a need to focus on the upper layers of the GWAC stack.

Some random thoughts expressed:

·  Closed versus open source issues - make it easier for new companies to implement industry standards to achieve interoperability – e.g. DNP, 61850, CIM, etc.

·  Separation of information models from PHY/MAC/NET layers can be helpful in achieving interoperability in higher levels of the GWAC stack. Example-> smart inverter WG doing this

Question: Why so little apparent progress in the last 10 years (since the GridWise Constitution in 2005)?

Observation: A lot has happened – just slowly (boiling frog analogy)

Smart phones are an example of exploiting lower levels of the GWAC stack to achieve value through the upper layers.

Enough change is happening with DER, storage, and utility business models to support focusing more on the upper layers – especially services and applications. All agreed that our industry conversation is still too low in the stack. The industry needs to start talking more about key services needed and classifying them.

Coming up with OT/IT design principles is important.

Observation: Small utilities often buy from smaller vendors with all-in-one solutions – they don’t have an enterprise architecture / IT staff of their own to handle integrations.

Multispeak based applications is an example – interoperability allows many small vendors to participate in the small utility market.

GWAC has an Interoperability Maturity Model (IMM). It is stil la challenge to answer what the ROI is for moving from maturity level X to level Y.

The fundamental new thing today from just a few years ago when the interoperability discussion was started is that we have a lot more stuff to integrate from more vendors with new data types and more of it. Can this observation help make a business case?

Observation: Grid 3.0 stated charter is around and in the context of pervasive DER.

Question: Is that the right focus?

Answer: Group seems to agree on yes – that is a good context for now.

Clarification: Pervasive DER is assumed to cover the “simpler” DER types and scenarios such as building management and load management in general.

Key Actor List

Review from Architecture Workshop. Need to identify well defined points of interoperability (WDPOI) and their characteristics across all levels of the GWAC stack for each.

·  ISO

·  TSO

·  Distribution System Operator (markets)

·  Distribution Operator (asset owner)

·  Aggregators/Third Parties – ESO

·  Substation Devices (breakers, transformers, cap banks)

·  Distribution Devices (e.g. reclosers, sectionalizers, regulators)

·  Sensors (non-operational – e.g. temp/pressure, quality)

·  Utility DER

·  Third Party owned/operated DER (e.g. Solar City)

·  Customer Interface – Revenue/Smart Meters

·  Customer Interface – DER (includes loads, HAS, BAS)

·  Distributed Processing and Communications Node

·  Communications Networks (FAN, WAN, LAN, HAN)

·  External parties and systems (e.g. wx, public safety)

Interoperability Cost/Benefit Discussion

It would appear that quantitative cost/benefit references are needed to facilitate making the business case for interoperability.

Several documents already exist but many if not most are qualitative. Some may have been ahead of their time and/or are not visible enough to be utilized. Existing documents include the SGIP IMC case studies and the GWAC interoperability benefits papers.

The group agrees that there is a need to perform a deep, quantitative analysis of the cost to integrate pervasive DER. Such an analysis would:

·  Highlight the high device count issue

·  Include avoided cost

·  Include an evaluation model

Ron Cunningham proposed a graphical approach to visualizing the value of interoperable system value:

Ron Cunningham to Provide Updated Diagram

Starting points for this analysis:

·  Regulatory filings for cost/benefit

·  Vendor white papers on standards implementation and resulting cost/benefit

·  Example: ESB implementation at Ameren

Procurement Issues

AEP says that they list standards in procurement – but still subjective as to which standards chosen – not necessarily based on a disciplined, business and technical requirements based analysis. AEP also requires certified products. They test in their lab or require testing in another certified lab. Profiles for key standards are important to ensure application level interoperability versus standards compliance.

RFP language often differs from contract language – procurement requirements sometimes relaxed.

Action: Need a philosophy of procurement of interoperability systems

Action: Need collaboration between procurement specialists and SME’s

Action: Need to develop procurement best practices for interoperability – a checklist at least

Focus on what is going to be heavily procured in the near future.

Action: Training is required. Need:

·  Examples

·  Language

·  Best practices / checklist

Success stories can be very helpful in explaining the value of interoperable systems

Look at European success stories as well.

Examples:

·  ABB 61850 white paper

·  SCE substation implementation of 61850

·  SGIP IMC white papers

·  California 2030.5

Approach: Look at what utilities are buying and interfacing to – then pick the relevant projects to highlight

Action: Pick popular, significant projects that have a holistic interoperable view and document them. Look at:

·  DOE projects

·  California EPIC projects

·  Past DTech and T&D presentations on implementations

Action: Select key use cases in manner similar to projects – search existing databases from SCE, CMS, SGIG, EPRI, others

Interoperability Information Repositories

Once we have gathered and developed this material, how is it published and maintained?

Action: We need a semantic web of data

All information resources need to be more searchable and accessible

Utilize semantic web technologies such as RDS

Note: some repositories not free

Approach: Use of academia/students via grants to help with collection and management

Side note on students – curriculum needs to be developed that highlights interoperability.

Action: Ensure that students are exposed to available information. Get them to recommend ways to make it fun.

Action: Need advanced visualization of complex systems – topology and relationships. GE tool demonstrated at SGIP IMC is an example of a good tool

Workforce Skills

Modeling

·  Information

·  Business

·  Application and service decomposition

·  In short – the discipline of systems architecture

Enterprise Architecture (EA) practice in an organization (utilities, vendors) – includes TOGAF certification

The disciplined of EA encompasses much of interoperability and develops a culture for it.

There are EA interest groups – EPRI’s led by Gerald Gray for example

Action: Create a best practices white paper for creating EA capability in an organization. Note that the SGIP IMC white paper touches on it.

Not every organization is institutionally capable of creating an EA capability – guidelines needed for those. Example – when and how to procure those services

Accelerating Deployment of Interoperable Systems

61850 and CIM specifically