Open Field Message (OpenFMB) Bus Project SGIP OpenFMB Working Group OpenFMB Priority Action Plan

What is Open Field Message Bus? Framework for distributed intelligent nodes interacting with each other Economical industrial internet technologies applied to Smart Grid Distributed resources communicating via common semantic definitions Grid-edge nodes processing data locally for control and reporting OpenFMB supports field-based applications that enable: Scalable peer-to-peer publish/subscribe architecture Data-centric rather than device-centric communication including support for harmonized system and device data Distributed logic as well as centralized logic                    

Industry Drivers for OpenFMB Leverage lessons learned across many industries from the rapid maturation and adoption of Internet of Things (IoT) technologies Optimize legacy and future assets Promote self-healing, resiliency, and improved power quality Integrate renewable and distributed energy resources into the Grid and flexibly manage two way power flow Support a Transactive Energy marketplace Facilitate new solutions and capabilities and reduce time-to-market

Guiding Principles Based on operational and functional requirements Use cases drive functional and operational requirements. Requirements determine and limit scope and success parameters Features added only when requirements demand it. Flexible architecture No “one size fits” all solution. Framework compatible with multiple data models, communications, and technologies Support multiple methods of communication and integration No reinventing the wheel Use existing standards, architecture patterns, and requirements where possible Time to market is key Solution must be good enough to meet market needs, not “perfect” Focus on business value and objectives Add features with most impactful business value first Due to limited resources, focus on high value use cases first Address “nice to have” features in future updates Collaborate with standards bodies SGIP coordinates with the NAESB, IEC, and other relevant SSOs as required Minimize or eliminate duplication of effort and scope Coordination takes time and effort, but it’s worth it No stranded resources Consider needs of existing environment Use of existing resources is a key success criteria Modify solutions as necessary to address existing environment. Security built-in from the beginning Security is a functional and operational requirement Apps run in the field autonomously and require secure, reliable operation Solution must be reliable and trustworthy

What’s Different About OpenFMB? Led by utilities (largest IOU, Muni, and Co-op) based on their priorities and interoperability demonstration experience OpenFMB reduces latency and creates distributed intelligence opportunities to manage local grids in the most efficient way based on local resources and conditions The data-centric bus secures information, data topic via data topic (analogous to securing data in a database, table by table) instead (or in addition to) of traditional method of applying security at the transport layer OpenFMB enables grid devices to speak to each other, e.g. meters, relays, inverters, cap bank controllers, etc. Enables legacy equipment to be retrofitted for new capabilities, features, and extended life Facilitates data integration across previously silo-ed domains within the utility

OpenFMB Expected Benefits Fostering innovative products and services Local intelligence with coordinated self-optimization where the volume of local data overwhelms the capability to transfer the data elsewhere Fast response when centralized sites are too far away to respond promptly Resiliency when portions of the grid are segmented Open, observable, and auditable interfaces at multiple scales for interoperability Interoperability with existing assets with no rip-and-replace Potential unified backhaul for reduced OPEX, simplified management, and enhanced security Unlocking stranded assets by building adapters and applications

Origin of Open Field Message Bus 2014 Duke Energy Coalition of the Willing (COW) 6 vendor partners Distributed Intelligence Platform (DIP) Peer-to-peer communications Internet technologies Goals Foster innovative products and services and COTS tools Distributech 2014 2015 COWII Testing and interoperability demonstration at Dtech 2015

Participants Utilities Ameren Services American Electric Power (AEP) CPS Energy Detroit Edison (DTE) Duke Energy Oklahoma Gas & Electric Pedernales Electricity Cooperative Southern California Edison (SCE) Southern Company Test Beds National Renewable Energy Laboratory (NREL) Academia, R&D, and Standards Setting Organizations EPRI IEEE NAESB NEMA OpenADR Alliance FREEDM Systems Center Vendors ABB Aclara Ericcson General Electric Green Energy ITOCHU Itron Kitu Systems LocalGrid Omnetric Real Time Innovations ViaSat Consultants Coergon EnerNex GridIntellect Xanthus Xtensible Solutions Government DOE FERC NIST ORNL PNNL

SGIP OpenFMB Project Process Develop Use Cases and Requirements Microgrid Unscheduled Disconnect Microgrid Reconnect Microgrid Operational Optimization Determine Semantic Model Needs IEC 61968/70 IEC 61850 MultiSpeak Develop Adapters and Applications Schemas Industrial Protocols Pub/Sub Distributed Intelligence Test Beds NREL Duke Energy CPS Energy Demos EPRI SGIP Dtech NAESB Standard Specification Reference Architecture

OpenFMB Project Timeline 2015 Feb - May May - July July - August September - February Use Case UML Modeling Application and Adapter Development Demonstrations SGIP Annual Meeting Nov. 3-5 (New Orleans) Use Case Meeting May 14-15 (NREL) Modeling Meeting July 8-9 (EPRI Charlotte) DistribuTECH 2016 Feb. 9-11 (Orlando, FL)

NAESB Standard Development Timeline 2015 2016 March - May June - August Sept.-Nov. Dec. Jan. – March Requirements Design Draft Task Force Voting 30 Day Public Comment 30 Day Membership Ratification OpenFMB TF F2F Meeting #3 (TBD) OpenFMB TF F2F Meeting #2 (July 8-9, 2015) OpenFMB TF F2F Meeting #1 (May 15, 2015) DistribuTECH 2016 Feb. 9-11 (Orlando, FL) OpenFMB Use Case Prioritization (April 2, 2015) NAESB Executive Committee Meeting on Feb. 2016 SGIP Engage 2015 (March 4, 2015)

How does OpenFMB relate to the GWAC* Stack? *Gridwise Architecture Council OSI stack, message centric middleware addresses layer 4/5. DDS addresses layers 4 through 6, and some of layer 7.

Data-Centric (OpenFMB) vs. Message-Centric Bus Message centric middleware addresses network interoperability, syntactic interoperability, and semantic understanding (GWAC Layers 2, 3, & 4). Message Centric Data Centric (DDS) Data-centric middleware (DDS) supports GWAC layers 2, 3 & 4 as well as Layer 5 (Business Context), allowing for simpler application code development, scalability, and fine-grain security on the data itself rather than the transport layer. Application Application Application Logic Application Logic Message Parsing and Filtering Data Centric Middleware (RTI) Message Caching Savings Message Parsing and Filtering Addressing, Marshaling Message centric middleware addresses network interoperability, syntactic interoperability, and semantic understanding (GWAC Layers 2, 3, & 4). Data-centric middleware supports those layers of the GWAC stack as well as Business Context (Layer 5), allowing for simpler application code development, scalability, and fine-grain security on the data itself rather than the transport layer. Message Caching & State Management Message Centric Middleware Discovery, Presence Marshaling, 32/64 Send/Receive Packets Send/Receive Packets

Overall OpenFMB Design Process Requirements Build Use-Case OpenFMB DataFlow Configuration IEC CIM UML OpenFMB UML Export Profiles Topics, QoS, Readers/ Writers OpenFMB XSD Convert XSD Pub/Sub Syntax Configure Middleware OpenFMB node OpenFMB node Adapter Adapter Device App

OpenFMB Conceptual Architecture Open Field Message Bus Pub/Sub Grid Resource Group A App Adapter Grid Resource Group B App Adapter Adapter App Adapter App Use Case 2 A C D Use Case 1 Use Case 3 A F E B D C B Data Device & App Use Case LEGEND A C B E F D The OpenFMB Framework is driven first and foremost by the use case. The use case defines the functional and non-functional requirements as well as the information model requirements and the specific data which needs to be communicated by the use case actors. Because there is no master/slave bus and the communication is truly peer-to-peer, the OpenFMB Bus enables use case actors to share data – but only the data absolutely necessary to support the use case – with minimal payloads across whatever transport medium is available. Actors in the system can support multiple use cases. Data communication is ignored by any actors in the system that are either not included in the use case or are not subscribed to the data traffic. Data has quality of service (QoS) capabilities to ensure delivery, data quality, delivery frequency, and other QoS metrics. Grid Resource Group C Adapter App

How will OpenFMB be secured? At least one, but not all need to be implemented System Boundary Network Transport Media access (layer 2) Network (layer 3) security Session/Endpoint (layer 4/5) security Host Machine/OS/Applications/Files Data & Information flows There are different places within a system that security can and should be applied. Traditionally network security has been applied at the transport layer (think TLS which underpins HTTPS) – everything going on to the network is encrypted and all connections are authenticated. With DDS’s security model you can secure information, data topic by data topic (analogous to securing data in a database, table by table). This is addressed by DDS Security

Questions? Stuart McCafferty SGIP, VP Operations OpenFMB Co-Chair smccafferty@sgip.org Dr. Stuart Laval Duke Energy, SG Technology Manager OpenFMB Co-Chair stuart.laval@duke-energy.com For more information, visit the SGIP website