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
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
Posting orders, reading orders, and trades
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:
Map the interactions for your flexibiblity related process and information to be exchanged
Identify the involved actors in the exchange of information
Identify which actor is going to provide and receive information upon request (reactively)
Check the UMEI list of available APIs and identify which one fits the purpose
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)
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 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
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.