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

2. 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                    

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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 (NREL)
Modeling Meeting
July 8-9 (EPRI Charlotte)
DistribuTECH 2016
Feb (Orlando, FL)

11. 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 (Orlando, FL)
OpenFMB Use Case Prioritization
(April 2, 2015)
NAESB Executive Committee Meeting on Feb. 2016
SGIP Engage 2015
(March 4, 2015)

12. 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.

13. 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

14. 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

15. 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

16. 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

17. Questions?
Stuart McCafferty SGIP, VP Operations OpenFMB Co-Chair
Dr. Stuart Laval Duke Energy, SG Technology Manager OpenFMB Co-Chair
For more information, visit the SGIP website