The UMEI defines a set of standard rules to enable an agnostic, adaptable, and modular combination of different APIs to link DSOs and market parties with flexibility market platforms, in coordination with other flexibility users.

This approach allows distributed communication without the need for a central hub.

In its current structure, the UMEI covers the following flexibility process phases:

• Prequalification phase – In this phase, basic master data like portfolios, grid nodes, etc are set up
• Pre-trading phase
  • Defining baselines, the expected power usage, for portfolios
  • Defining flexibility zones – the expected demand for flexibility and aggregation of resources
  • Extracting this information, along with market and portfolio information, for use in the next phase
• Trading phase
  • Posting orders, reading orders, and trades
• Post-trading phase
  • Providing meter readings for assets used in trades

OpenAPI [https://www.openapis.org] was used as the definition language. This is the most common and well-supported way of defining APIs accessible using the standard web technologies of today – JSON over HTTP.

Steps for the implementation:

1. Map the interactions for your flexibiblity related process and information to be exchanged
2. Identify the involved actors in the exchange of information
3. Identify which actor is going to provide and receive information upon request (reactively)
4. Check the UMEI list of available APIs and identify which one fits the purpose
5. The actor identified in 3. will be the one to host the chosen API (implement server-side code) and make it available for the other(s)
6. For the implementation, actors can leverage on OpenAPI features enabled by Swagger and generate client and server-side boilerplate cod

The setup process for the implementation implies that there’s the possibility to have more than one hosting actor for the system, and no need for a mediation platform, making the UMEI a truly distributed data exchange interface. This makes the usage of the UMEI particularly straightforward for actors which act moslty as UMEI API clients (case of DSO and FSP), since they just need to invoke a API endpoint to send and retrieve information.

The UMEI prototype is already available on GitHub https://euniversal.github.io/umei-api-specification/

The UMEI is open to be used by any interested parties, being set as an open-source component to enable market based flexibility.

Updates to the specifications are already being developed in other research projects tackling TSO-DSO coordination and electric mobility. Developments can also be proposed by the users or potential new users, whenever new needs arise, since all can collaborate to its evolution, through the GitHub.

Further technical enhancements may include:

• Complementing the UMEI with APIs to allow:
  • Compatibility with TSO (e.g. for pre-qualification purposes)
  • Inclusion of other flexibility process steps (e.g. financial settlement)
  • Flexibility register synchronization
• Developing and distributing an official client library, in one or more languages
• Developing and distributing an official implementation validation test suite or set of tools