[Reference] mvs functional and non functional requirements list

[Bachibouzouk]

A detailed status of the E-Land requirements can be found in the readthedocs. Here, an overview of the statuses as well as the always updated ToDo list is displayed.

List of functional requirements:

• FUN-MVS-01 - Solving an energy system optimization model
• FUN-MVS-02 - Automatic setting up of an energy system optimization model
• FUN-MVS-03 - Manual setting up an energy system optimization model
• FUN-MVS-04 - Optimisation Results
• FUN-MVS-05 - Production Assets
• FUN-MVS-06 - Assets of Energy Conversion
• FUN-MVS-07 - Optimisation goal
• FUN-MVS-08 - Electricity cost model
• FUN-MVS-09 - Load profiles
• FUN-MVS-10 - DH cost model
• FUN-MVS-11 - PV data
• FUN-MVS-12 - Battery data
• [~] FUN-MVS-13 - CHP data
• FUN-MVS-14 - Thermal storage data
• FUN-MVS-15 - Autonomous operation data
• FUN-MVS-16 - Economic data
• FUN-MVS-17 - Constraints

List of non-functional requirements:

• NF-MVS-01 - MVS pre-processing tools for LES optimization model input
• NF-MVS-02 - MVS post-processing tools for LES optimization model output/results
• NF-MVS-03 - Communication interface between MVS and ESB
• NF-MVS-04 - Unit commitment time step restriction
• NF-MVS-05 - Interface for technical parameters and model
• NF-MVS-06 - Interface for economic parameters and model

ToDos:

KPI

• Degree of sector-coupling
• Degree of autonomy (energy balance) -> percentage of demand covered by local generation? (WP5.3)
• [~] Percentage of self-supply (hourly)
• [~] Percentage of self-consumption (hourly)
• Total CO2 emissions (kg/a)
• CO2 emissions in kg/kWhel
• Peak power supply from the energy providers (WP5.3)
• Storage utilization efficiency (WP5.3)
• Number of complete cycles (WP5.3)

Constraints

• Maximum CO2 emission constraint (limit of kg/a) or multi-objective introduction by setting emission costs
• Minimal degree of automonomy
• Operating reserve constraint (to be developed in cooperation with the end-users)
• Cost constraint is for now disregarded. As always the cheapest supply solution is identified, limiting the overall NPC would only result in infeasible solutions and a termination of the MVS. Cost constraints considering specific technologies can be covered by adapting the maximumCap.

Asset types

• [~] Address geothermal conversion assets (as renewable fuel source, as renewable source?)
• Thermal storages: Now defined analogously to electrical storages, but model to be improved by the oemof_thermal object. Would be defined as a new type in the EPA data bank.
• CHP with fix ratio between the heat and electricity output can already be simulated. For a chp with a variable ration between those two outputs, we need to add the specific chp oemof asset to the possible inputs.
• When using two conversion objects to emulate a bidirectional conversion assets, their capacity should be interdependent. This is currently not the case (Transformer objects describing in/out of a bus should be connected #24, Develop needed constraints for MVS (ongoing) #133 )

Features

• Pre-processing of renewable generation sources: Integrating downloads from renewable ninjas or calculation with pvfeedinlib (using longitude and latitude, module or efficiency, performance ratio)
• Defining default values for the BESS (possibly requirement a)) could also take place in the EPA.
• Creating a parser for the json file so that EPA can read it
• EPA development by ICOM, possible changes for the MVS API

Optional

• Finer time-resolution of eg. 15-minute time steps

Testing

• Investment optimization benchmark tests - check if expected capacities are installed, eg. for PV.
• Economic evaluation benchmark test - check if NPC and LCOE are calculated correctly
• LCOE benchmark test for LCOE - check if LCOE is calculated correctly for one sector as well as for multiple sectors with different conversion factors
• Excess energy benchmark test

Edited by smartie2076, 2021-03-12

[smartie2076]

I am considering to document the requirements in the readthedocs. @Bachibouzouk @SabineHaas what do you think of this?

I have already created an rst file for this in this branch. A preview is this:

2020-09-30-Requirements-Progress.pdf

We could then only gather the to-dos here (the loose ends so to speak) to discuss them?

[Bachibouzouk]

I think it is a good idea, it provides a list of requirement in a nice format :)
Then you would erase a requirement from here once it is in the rst file?

[smartie2076]

I have all requirements and their current status in the rst file.

I think it is a good idea, it provides a list of requirement in a nice format :)

Nice :)

Then you would erase a requirement from here once it is in the rst file?

Hm, I would probably have a checklist on top just with the general requirement titles (and ids). The exact requirement definition as well as the detailed answer would only be in the rst file.
Below that, I would add a checklist with the todos, which I would always update if new ones are identified.

We can then used this issue to get a quick overview over our requirements, and use it in our e-land monthly meetings.

[smartie2076]

@Bachibouzouk @SabineHaas I now updated the first entry of the issue, so that tracks all needed features to be integrated. I merged the extended requirements and statuses into the reathedocs.

[Bachibouzouk]

Could this issue be closed now? @smartie2076 ?