Requirements for the Multi-Model Infrastructure (MMI)¶
28 November 2023
At the start of the MMviB project, two requirement workshops were organised with the consortium. The goals were threefold: first, to generate ideas for desired features of the MMI as a long-term vision; second, to reach a consensus on the objective of this project within that vision; and third, to promote trust and enhance understanding among partners through a collaborative and co-created effort.
To gain a solid understanding of the overarching issues, namely the WHY (needs) and WHAT (features) of MMI, the following key questions guided our discussion in the workshops:
What kind of use cases do we envisage?
What cannot be done now by individual models, and what is MMI’s added value?
What kind of decisions to make with the multi-models?
What features or services are required in the MMI?
What the MMI will need to connect multi-models?
What kinds of models are to be coupled? What is their operational principle (e.g., AMB, optimisation)?
In what manner should the models interoperate?
What information do the models exchange? How often?
We used a five-step brainstorming process (i.e., idea generation, pruning, grouping, defining features, and prioritisation) to elicit, organise and summarise the needs and features. They are summarised and reviewed in five categories and explained in this MMI requirement document.
1. Infrastructure deployment¶
This category addresses the issues to avoid or reduce vendor- or other types of lock-in.
Features |
Priority |
Comments related to Needs |
|
|---|---|---|---|
1.1 |
The infrastructure should be deployable on a single computer or within an organisation. |
Critical |
|
1.2 |
The infrastructure shall not depend on a single party. |
Critical |
2. Model description and alignment¶
This category addresses prerequisites for multi-model connection: what the models need to adhere to and what the MMI need to provide to allow model participation.
Features |
Priority |
Comments related to Needs |
|
|---|---|---|---|
2.1 |
Provide a generic format for model description. |
Critical |
The model description shall include, e.g., objectives, data requirements, time scales, to help general understanding of a model. It shall be human readable, and ideally also machine readable. This feature is needed to support model selection. |
2.2 |
Provide a common data model/format for input/output data |
Critical |
Consistent synthetic representation of data exchanged in multi-models |
2.3 |
Allow model connection across multiple geographic, time and other scales |
Critical |
Alignment of multiple levels of model granularity. Example of applications: evaluation of macro-level decisions on a micro-level; couple high-level energy scenario models to detailed dynamic simulation models; couple economic market models to technical models. |
2.4 |
Provide a common energy system database/dataset for model input and configuration |
Important |
data sharing, alignment, consistency |
2.5 |
Explicit description of model assumptions |
Important |
Understanding and potential alignment of model assumptions |
2.6 |
Queryable model assumptions |
Nice to have |
Support transparency and understanability among other |
2.7 |
Allow inclusion of external ontologies in addition to the standard model description provided by MMI |
Nice to have |
Alignment of conceptual representations |
3. Model connection and multi-model set-up¶
This category addresses how to connect individual models and to set up a multi-model
Features |
Priority |
Comments related to Needs |
|
|---|---|---|---|
3.1 |
Provide interfaces for model connection to allow multi-model creation and connection |
Critical |
Reusable interfaces between models, that allow for easy multi-model creation in future API and/or UI; to easily add and remove models |
3.2 |
The interface shall support different types of model interaction |
Critical |
Support multiple “interaction schemes” (of different types of models, e.g., agent-based model, excel model, optimization model) and to minimize required adaptations to the individual models |
3.3 |
Provide a method to configure the models that uses the infrastructure |
Critical |
Statical or dynamical configuration of models |
3.4 |
Provide a method to communicate uncertainties and source thereof (model inputs and outputs) |
Critical |
Communicate the uncertainty of model results |
3.5 |
Provide a model repository |
Important |
For model search and selection capabilities |
3.6 |
Secure and authorized connection and communication when needed |
Important |
Manage access and communication rights, possibly also for paid use |
3.7 |
Identification or flagging of potential multi-model interaction problems |
Important |
Support model selection capabilities and model interoperation |
3.8 |
Model repository/catalogue with “app store” |
Nice to have |
|
3.9 |
Model discovery and selection based on requirements |
Nice to have |
Find the right model(s) that fit the purpose |
3.10 |
Dashboard/GUI for multi-model selection, connection and configuration |
Nice to have |
Model selection capabilities by human |
4. Model interoperation¶
This category addresses what is needed for model interoperation (i.e. interaction) after a multi-model is set up
Features |
Priority |
Comments related to Needs |
|
|---|---|---|---|
4.1 |
Allow for human-in-the-loop control of model interaction |
Critical |
|
4.2 |
Allow for fully-automated model interaction |
Critical |
|
4.3 |
Standardized communication protocol |
Critical |
Informing, e.g., assumptions of one model with outputs from another model |
4.4 |
Provide an orchestration mechanism that allows for control of models |
Critical |
This includes, e.g. start, stop, pause, continue, reset, error report and handling, have keep-alive pings. |
4.5 |
The orchestration mechanism shall be in a decentralized way |
Critical |
|
4.6 |
Provide logging and tracing |
Critical |
|
4.7 |
Provide debugging capabilities |
Critical |
|
4.8 |
Provide backward compatible communication protocol |
Nice to have |
|
4.9 |
Support dynamic real-time model interaction |
Nice to have |
Fit for real-time applications |
4.10 |
Support hardware-in-the-loop |
Nice to have |
Fit for Digital twin applications |
5. Model experimentation and output¶
This category addresses what is needed for model interoperation (i.e. interaction) after a multi-model is set up
Features |
Priority |
Comments related to Needs |
|
|---|---|---|---|
5.1 |
Provide experiment management |
Critical |
For documenting model set-up, version, scenarios, parameters, runs, etc. |
5.2 |
Provide multi-model output result management |
Critical |
Link result to experimental setups; who saved the result and where |
5.3 |
GUI MM output analysis |
Nice to have |
Output analysis with respect to MM experimental set-up |
5.4 |
Provide a set of experiment scenarios for a given energy system configuration |
Nice to have |
To assist experimental set-up; Case study repository |