Learn
Select a topic pelow to learn more about OpenFMB, or check out some tutorial videos.
Grid Edge Controls Use-Cases
The OpenFMB standard facilitates edge computing and coordinates Distributed Energy Resources (DERs).
Data Model Enables Pub-Sub Protocols
OpenFMB explicitly defines the information exchange (e.g. messages) between devices on the grid.
An Open Gitlab Hosted Repository
OpenFMB use cases, information models, and message formats can be found in our GitLab repository.
Grid Edge Controls Use-Cases
The OpenFMB standard is designed to facilitate making decisions nearest to its data source, facilitating edge computing and coordinating Distributed Energy Resources (DERs).
Distributed Circuit Segment Management
OpenFMB members maintain a standardized information model and interfaces with many communication fabrics. OpenFMB is an enabling technology that is critical to the integration of Distributed Energy Resources (DERs) and grid automation in a way that increases the resiliency of the distribution network.
The energy consumers and regulators expect that when additional sources of energy are added to the distribution system, the system should become more resilient to disturbances. It seems intuitive that when there are more options for providing power, particularly when a major disturbance is encountered, that the power system would be better equipped to continue providing power.
This is why the DER Circuit Segment Management use case is the preeminent focus area for OpenFMB. OpenFMB enables distributed edge intelligence to be deployed into the power system so that local orchestration of all grid resources can be performed as close to the resource as possible. These decentralized grid architectures have been researched at length, and Pacific Northwest National Laboratory maintains a history of the advantages of these architectural approaches on their PNNL: Grid Architecture – Advanced Concepts page.
Data Model Enables Pub-Sub Protocol
OpenFMB explicitly defines the information exchange (e.g. messages) between devices on the grid. In this way, it’s not a communication protocol like 61850, DNP3, or Modbus. Instead, it enables secure and scalable publish-subscribe communications for distributed decision making regardless of the underlying communications mechanisms.
The high-level properties of OpenFMB are codified in the NAESB Retail Market Quadrant Model Business Practice RMQ.26 – Open Field Message Bus (OpenFMB) Model Business Practices (MBPs). This standard outlines the need to use established publish-subscribe transport layers (such as NATS or MQTT) to authenticate and exchange information between field equipment as a common messaging bus, and to develop a robust set of structures and topics that are exchanged by first establishing use-cases of the objectives that would be achieved with field coordination, and use those concrete objectives to inform the data model and topic decomposition.
Open Field Message bus standard therefore focuses on providing a common data-model and serialization mechanisms compatible with multiple application technologies that can be transported over any number of pub-sub message busses to allow sharing of that data-model between disparate energy resources that participate in the distribution system.
An Open Gitlab Hosted Repository
OpenFMB use cases, information models, and message formats can be found in our GitLab repository.
Various OpenFMB components are available in the OpenFMB Gitlab project. A brief orientation of that repository is provided here.
- The Use-cases are captured in a collection of repositories under the Gitlab project use-cases · GitLab
- The Platform Independent Model (PIM) is an Enterprise Architect UML representation of the data representation, and how each element in the data model is linked to the various Sub-Processes that are all linked to the high-level.
The model draws heavily from and attempts to maintain a harmonious relationship with the CIM and 61850 sister models but is use-case driven and is a domain-specific model that fills a different need. An example activity diagram of DER Circuit Segment Management use case is below.
The data-models for the topics exchanged on the message bus are outlined in the OpenFMB Information Model folder. In this screenshot you can see the Discrete, Event, Reading, and Status messages that can be exchanged to represent the complete information exchange with a recloser module below.
Modules
When modules want to share sub-structures, they are declared in the Common module, and then imported into the particular modules. (This module is really a library of sub-structures that are shared by the other modules).
Other modules include:
- Breaker
- Cap Bank
- Circuit Segment Service
- ESS
- Generation
- Interconnection
- Load
- Meter
- Recloser
- Regulator
- Reserve
- Resource
- Solar
- Switch
The Platform Specific Modules (PSM) provide language-specific harnesses for technology stacks that might want to interoperate with a message exchange bus. The most widely utilized PSM is protocol buffers (Protobuf):
The Protobuf encoding and programming-language-specific presentation stubs for each profile that are used as the OSI layer 6-Presentation data descriptions that can encode information on any layer 5-session pub-sub protocol (NATS, MQTT, etc.).
Subscribe Topic Structure
OpenFMB provides a common data model and prescribes the use of a publish-subscribe bus with structured topics.
The topic structure of OpenFMB consists of a common OpenFMB prefix followed by the module, message profile, and finally the device id (mRID/UUID).
An example topic using MQTT might be:
- openfmb/solarmodule/SolarStatusProfile/540b292a-e600-4ae4-b077-40b892ae6970
And the equivalent NATs topic with dot separators:
- openfmb.solarmodule.SolarStatusProfile.540b292a-e600-4ae4-b077-40b892ae6970
The topic structuring allows for a great deal of flexibility in what each program connected to a bus may be interested in subscribing to, with the potential of using wildcards when useful.
Common Message Information
Every message contains an mRID (UUID) to identify the device and another to uniquely identify the message. Additionally, every message requires a timestamp.
Each profile will use some subset of the following message types which represent the choreographed message exchange patterns that are facuiliated by the message bus.
- Reading Commonly provides meter-like readings
- Status Periodically published from each device. They contain general state information about the device such as switch state, meter readings, storage, and state of charge.
- Event Event messages are published upon state changes that provide incremental updates to the periodic Status message.
- Control Updates to the lower-level control contstraints, ex: a power interchange target that provides the Point Of Common Coupling intertie flow targets over a time range (commonly referred to as a schedule).
- Discrete Control Immediate requests to change device state.
