Open Field Message Bus (Openfmb) Model Business Practices

Open Field Message Bus (OpenFMB) Model Business Practices

Table of Contents

Executive Summary 1

Introduction…………………………………………………………………………………….….

Business Processes and Practices 1

RMQ.26 – Overview 1

RMQ.26.1 – Principles 1

RMQ.26.2 – Definitions, Abbreviations and Acronyms 1

RMQ.26.2.A – Business Definitions 1

RMQ.26.B – Technical Definitions 1

RMQ.26.2.C – Abbreviations and Acronyms 1

RMQ.26.3 – Model Business Practices 2

RMQ.26.3.1 – General Practices for OpenFMB 2

Functional Model Business Practices 2

Non Functional Model Business Practices 2

Open Field Message Bus (OpenFMB) Reference Architecture 3

Overview 3

Systems Architecture 3

Components Architecture 3

OpenFMB Logical Architecture 3

Platform Independent Model (PIM) 3

Platform Specific Model (PSM) 4

Data Exchange Patterns 4

Security Architecture 4

Other Considerations 4

OpenFMB Platform Independent Model 5

OpenFMB Platform Specific Model 6

DDS Reference Implementation 6

MQTT Reference Implementation 6

Other Reference Implementations 6

List of XML Schemas (XSDs) 6

Examples 6

Appendix 7

Appendix A – Use Cases, Interactions and Data Definitions 7

ÓNAESB 2015

EXECUTIVE SUMMARY

In the power utility industry today, there are many electric grid devices that support new and different features and functionality both within substations and along the transmission and distribution lines. Unfortunately, these devices use a variety of communication and protocol standards, in many cases proprietary in nature, which have prevented most of these devices from being capable of communicating peer-to-peer with other devices in the field, let alone exchange data and information for local intelligence and decision making.

OpenFMB is a specification for a non-proprietary and standards-based field message bus to enable these power systems field devices to interoperate. This standard will be used by device vendors and/or utilities to develop the technical requirements to be implemented on field devices that will enable them to communicate directly with each other via a field message bus as well as to centralized data centers as they do today without a significant increase in the integration cost or complexity.

The benefits achieved with deployment of the OpenFMB are significant, including:

1. Enabling devices to communicate quickly with each other in an open, secure, and scalable fashion, which will foster new and innovative utility grid control and management features and functionality that were not feasible before. The result is a more resilient, reliable, and robust grid that is integrated with the supply-side operations and demand planning.

2. Enabling open competition of grid field devices and reducing proprietary technology dependence. This will fuel innovation in the marketplace and reduce supply chain risk.

3. Enabling the capability to leverage existing sensors and communications infrastructure of current smart grid investment by unlocking the data those devices are already collecting.

4. Enabling better integration of grid devices and services to end-use customers, especially in the wake of the fast growth of Distributed Energy Resources and the advent of transactive energy.

This specification defines a reference architecture platform comprising internet protocol (IP) networking, Internet of Things (IoT) messaging protocols, standardized common semantic models, messages, and services to enable the secure, reliable, and scalable communications and peer-to-peer information exchange between devices on the electric grid.

A critical component of the proposed OpenFMB standard is the development of the common semantic model or layer to serve as the common language for the messages to be exchanged between field devices. The platform-independent data model of the common semantic layer will expand upon the initial work that has been based upon the IEC CIM (Common Information Model) with additional references and/or mappings to other key standards, such as IEC 61850 and SunSpec.

With the implementation of the OpenFMB standard, devices from different vendors and utilities will, in fact, be able to interoperate directly or through gateway technologies that act as a bridge, translator, or adapter for legacy protocols. This specification defines the building blocks that consist of device types, utility legacy protocols (DNP3, Modbus, IEC 61850 MMS/GOOSE, C12, etc.), IoT protocols, and use-case application logic that may be involved in this reference architecture.

INTRODUCTION (This Section needs to be modified for OpenFMB)(Stuart Laval and Terry Saxton)

The North American Energy Standards Board (NAESB) is a voluntary non-profit organization comprised of members from all aspects of the natural gas and electric industries. Within NAESB, the Retail Electric Quadrant (REQ) and the Retail Gas Quadrant (RGQ) focus on issues impacting the retail sale of energy to Retail Customers. REQ / RGQ Model Business Practices are intended to provide guidance to Distribution Companies, Suppliers, and other Market Participants involved in providing energy service to Retail Customers. The focus of these Model Business Practices is the Energy Services Provider Interface.

The purpose of ESPI is to provide a consistent and broadly applicable interface to enable Retail Customer Authorization of exchange of EUI from Data Custodians to Third Parties. It is anticipated that Third Parties will desire to offer Retail Customers raw and/or enriched analysis of EUI. EUI is expected to reside with a Data Custodian. It is desired that the Third Party can provide this service only through the request or direction of the Retail Customer and in coordination with the Data Custodian. ESPI describes the mechanisms by which this orchestrated exchange may be enabled. Note that the decision to implement ESPI should be applied within the context of existing policies, practices and the requirements of the Applicable Regulatory Authority.

For the purpose of the descriptions of interactions in ESPI, actions of contracted agents of a Distribution Company are considered the actions of the Distribution Company. However, ESPI is not necessarily intended to apply specifically to interactions between contracted agents of Distribution Company and the corresponding Distribution Company.

These Model Business Practices are voluntary and do not address policy issues that are the subject of state legislation or regulatory decisions. These voluntary Model Business Practices have been adopted by NAESB with the realization that, as the industry evolves, additional and amended Model Business Practices may be necessary. Any industry participant seeking additional or amended Model Business Practices (including principles, definitions, data elements, process descriptions, and technical implementation instructions) should submit a request to the NAESB office, detailing the change, so that the appropriate process may take place to amend the Model Business Practice.

Business Processes and Practices

REQ.26 Overview (Stuart Laval and Larry Lackey)

{this section will provide information regarding the background information on OpenFMB}

{this section will describe industry drivers for OpenFMB standard. This include, but not limited to the IoT technology advancement, power industry DER adoption, and the state of smart grid standards for distribution grid.}

· History – Duke’s Coalition of Willing (COW) activities in the past two years

· Smart grid current state and future needs including the rising of DER and its impact on utility grid.

· IoT technology overview and its impact on power industry.

· Why OpenFMB – industry drivers

· Overview of Smart Grid and DER Integration

· Overview of Smart Grid standards

· Overview of IoT technology and standards development

REQ.26.1 Principles (Joe Zhou)

{this section will describe the purpose and objectives of establishing the OpenFMB Reference Architecture}

REQ.26.1.1x Purpose – to establish a common reference architecture for vendors and utilities to build OpenFMB enabled devices

REQ.26.1.2x Objectives – to enable field device interoperability and deliver desired functionality for local intelligence and device data exchange.

REQ.26.2 Definitions, Abbreviations and Acronyms

REQ.26.2.A Business Definitions

RXQ.0.2.1 [A: This text included a an example for font for definitions.]

REQ.26.2.B Technical Definitions

REQ.21.2.1t [A: This text included a an example for font for definitions.]

REQ.26.2.Cx Abbreviations and Acronyms

Abbreviation / Acronym / Meaning /

REQ.26.3x Model Business Practices

REQ.26.3.1x General Practices for Open Field Message Bus (OpenFMB)

REQ.26.3.1.1x Overview of Smart Grid and DER Integration

REQ.26.3.1.2x Overview of Smart Grid standards

REQ.26.3.1.3x Overview of IoT technology and standards development

1.1 REQ.26.3.2x Functional Model Business Practices (subsection of 26.3.x) (Stuart Laval, Terry Saxton, and Larry Lackey)

{this section will include a set of functional requirements to drive the architecture and design of the OpenFMB standard. The focus of the requirements will be on the Open Field Message Bus, which defines what and how grid field devices can communicate with each other. The inner workings of the device (as part of the Distributed Intelligence Platform architecture) is for reference only, and is out of scope for this specification.}

Requirements No. / Requirements Description / Requirements Category / Node Classification /

1.2 Non Functional Model Business Practices (Larry Lackey and Stuart Laval)

{this section will include a set of technical requirements to drive the architecture and design of the OpenFMB standard. This include but not limited to security, performance, scalability, flexibility, reusability, maintainability, etc.}

Requirements No. / Requirements Description / Requirements Category / Node Classification /

2. Open Field Message Bus (OpenFMB) Reference Architecture

2.1 Overview (Joe Zhou)

{this section will include content adopted from Duke Energy DIP architecture document. Parts of the DIP architecture may be considered “informative”}

2.2 Systems Architecture (Jim Waight)

{this section will include the DIP architecture and how it can enable large scale control architecture of the power grid of the future, including references to other architecture models (IEC SGIM, GWAC Stack, etc.))

2.3 Components Architecture (Stuart Laval)

{this section will mostly focus on the details of the “Node” classification. The classification can be both roles- and functions- based in order to support a flexible deployment architecture. Security roles and functions should be part of the model. }

Categories that can drive the node classifications are:

· Device business functions and operational roles (data collection, control, etc.)

· Device location (relative to where it sits on the grid, substation, distribution line, utility DER, prosumer DER, grid edge, etc.)

· Security levels (critical infrastructure, etc.)

· Ownership (utility, prosumer, third party, etc.)

· ……

2.4 OpenFMB Logical Architecture (Larry Lackey)

{this section will describe the OpenFMB Logical Architecture, its layers and components. Note that this is not the same as DIP architecture which focuses on the overall systems, the OpenFMB focuses on the approach for devices to interoperate. The OpenFMB architecture will follow the OMG Model-Driven Architecture (MDA) design principles, best practices of SOA and IEC TC57 Reference Architecture, and leverage Industrial Internet of Things (IIoT) protocol architectural best practices and standards.}

2.5 Platform Independent Model (PIM) (Shawn Hu, Jim Waight, and Terry Saxton)

{this section will describe the approach to develop the OpenFMB Platform Independent Model (PIM). OpenFMB PIM will be developed from two key reference models (IEC CIM and IEC 61850 information model), while considering other smart grid models that also exist (MultiSpeak, OpenADR, ESPI, SEP 2.0, FSGIM, etc.) Note that the goal of this is not to harmonize CIM and 61850, but to derive a model from them to cover data definition to be exchanged using OpenFMB.}

2.6 Platform Specific Model (PSM) (Shawn Hu, Jim Waight, and Terry Saxton)

{this section will describe the approach to go from OpenFMB PIM to PSM. The candidate PSM representations are many, but we will start with XSD for protocols (Web Services, REST, XMPP, MQTT, etc.) that support XML data representation, IDL (Interface Definition Language) for DDS (Data Distribution Service). The approach to go from PIM and PSM will follow IEC TC57 methodology.}

2.7 Data Message Exchange Patterns ()

{this section will focus on the logical data exchanges patterns (using SOA best practices)m and map them to physical protocol data exchange pattern implementations. For example, DDS using the concept of QoS (Quality of Service) to define how data can be exchanged between devices. The OpenFMB DEP will be mapped to DDS QoS definitions. We will also review and leverage patterns defined in IEC 61968-100. In addition to a common information model and canonical message definitions, a consistent and detailed DEP design is critical to the device interoperability using OpenFMB.}

2.8 Security Architecture (Larry Lackey)

{this section will describe the security architecture to enable secure, reliable and scalable OpenFMB implementations.}

2.9 Other Considerations

3. OpenFMB Platform Independent Model (Shawn Hu)

{this is the information model, in UML class diagram format}

4. OpenFMB Platform Specific Model (Shawn Hu)

{this is the technology specific models generated from the PIM per each data exchange requirements from the use cases, including but not limited to DDS, MQTT, JSON, etc.)

4.1 DDS Reference Implementation (Stuart Laval)

4.2 MQTT Reference Implementation (Larry Lackey and Stuart Laval)

4.3 Other Reference Implementations

4.4 List of XML Schemas (XSDs) (Shawn Hu)

4.5 Examples ()

5. Appendix

5.1 Appendix A – Use Cases, Interactions and Data Definitions

{this section documents the use cases, interactions (sequence diagrams) and high level data definitions from the SGIP use case effort for OpenFMB.}

Page 12