E-LAND requirements of the MVS¶

Functional Requirements¶

FUN-MVS-01 - Solving an energy system optimization model¶

Description: The MVS shall solve an energy system planning optimization problem and provide the optimal sizing of individual assets.
Rationale: Basic operation of MVS.
Priority: HIGH
Progress: Done
Progress message

The MVS can solve energy system planning optimization problems and identify the optimal additional capacities of chosen assets. In-code validation checks, unit tests and benchmark tests were added to ensure that the simulation runs smoothly and correctly.

Notes

As with all simulation tools, there are always possibilities to improve the tool, specifically to address current limitations (comp. Limitations).

FUN-MVS-02 - Automatic setting up of an energy system optimization model¶

Description: The MVS should accept modelling parameters regarding the LES in a specific format.
Rationale: Currently MVS supports the Oemof model. The rationale is to support external entities or users with no experience in Oemof, by automatically generating the respective Oemof model for the agreed format
Priority: HIGH
Progress: Done
Progress message

The MVS accepts simulation data provided as csv files and automatically sets up an energy system. It also supports the integration into the Energy Planning Application (EPA) by providing a parser for the interfaces of the two tools.

FUN-MVS-03 - Manual setting up an energy system optimization model¶

Description: The MVS shall support adding specific components/constraints from a set of options to an energy system optimization model.
Rationale: Basic operation of MVS
Priority: LOW
Progress: Done
Progress message

It is possible to add as many components as needed to the energy model that is to be simulated with the MVS. They can be divided into following asset types:

Details on how to model different assets are included in the model assumptions (see Component models).

Notes

Energy excess sinks are automatically added by the MVS to enable energy system optimization and do not have to be added by the energy system planners.

In the future, it may be possible to add energy shortage sources, which would allow energy systems with a defined annual supply shortage. While this mostly will not result in an energy system many operators would require, it would also have benefits for the debugging of energy systems, as infeasible energy systems would be easier to evaluate and specific debug messages could be displayed.

FUN-MVS-04 - Optimisation Results¶

Description: The MVS shall provide the results of the optimisation process upon completion of calculation in a specific format, which include at least information related to asset costs (CAPEX and OPEX), sizes, as well as aggregated energy flows and overall system performance (autonomy, renewable share, losses).
Rationale: Basic operation of MVS.
Priority: HIGH
Progress: Done
Progress message

The results of the MVS simulation are post-processed, and result in numberous key performance indicators (KPI). Following information is calculated for an economic evaluation of the energy system:

Capital and operational expenditures (capex, opex) per asset, both as annuities as well as present costs. This includes also the first-time investment costs (FIC), the replacement costs minus residual values, and the costs for asset dispatch (equations compare Economic Dispatch).
NPC and annuity of the whole energy system
Levelized cost of energy (LCOE) of the energy system, in electricity equivalent
Levelized cost of an energy carrier in electricity equivalent (LCOEleq) for each energy carrier in the energy system
Levelized cost of asset dispatch, calculated from the annuity of an asset and their throughput

Additionaly, a number of technical parameters are calculated both the energy system and the individual energy vectors:

Dispatch, aggregated energy flows as well as peak flows of each asset
Renewable share
Renewable share of local generation
Degree of autonomy
Degree of net zero energy
Onsite Energy Matching (OEM)
Onsite Energy Fraction (OEF)
Annual excess energy
Annual GHGeq emissions and specific emissions per electricity equivalent

Notes

Currently in discussion is the implementation of a so-called degree of sector-coupling (see issue 702). This is a novel key performance indicator and would be integrated in addition to above mentioned parameters.

FUN-MVS-05 - Production Assets¶

Description: The MVS should consider a diverse type of production assets in the energy model i.e. PV, BESS, CHP, Thermal Storage
Rationale: Enable support of multi-vector production and storage assets.
Priority: HIGH
Progress: In-progress
Progress message

The MVS is able to simulate a wide range of assets:

PV plants, wind plants
Battery Electricity Storage Systems (BESS), via generic storage object
Thermal storages, via generic or thermal storage object
Power plants as simple generators.
And many more (see below)

ToDo

A CHP with fix ratio between the heat and electricity output can already be simulated, but has not been tested. For a CHP with a variable ration between those two outputs, we need to add the specific CHP asset to the possible inputs.

FUN-MVS-06 - Assets of Energy Conversion¶

Description: The MVS should consider assets which convert energy from one vector to another i.e. CHP, geothermal conversion (heat pump)
Rationale: Integration of the multi-vector approach in the MVS.
Priority: LOW
Progress: Done
Progress message

The MVS already covers generic conversion assets. How the generic definition can be applied to the individual assets is explained here. This includes

ToDo

A CHP with a variable share of heat and electricity output is currently not implemented. It could be added as a new oemof asset type.

When using two conversion objects to emulate a bidirectional conversion assets (eg. charge controllers, bi-directional inverters), their capacity should be interdependent. This is currently not the case, as explained in the limitations.

FUN-MVS-07 - Optimisation goal¶

Description: The optimisation process should take into account: Increasing the degree of autonomy of the LES, system costs minimization, and CO2 emissions reduction. Optional extension of the MVS is to allow for multi-objective optimisation.
Rationale: Different optimisation goal shall be supported for covering the different perspectives of the possible end-users.
Priority: HIGH
Progress: Done
Progress message

In general, the MVS aims to minimize the energy supply cost of the local energy system. Additionally, a number of constraints can be activated:

FUN-MVS-08 - Electricity cost model¶

Description: The MVS model shall be provided with data defining electricity grid supply regarding: a) kWh prices (both import and export from/to the grid), b) kWh/h prices (time series of prices), c) Constraints of the interconnection with the main grid (e.g. substation capacity)
Rationale: Information necessary for building the MVS Multi-vector Model.
Priority: HIGH
Progress: Done
Progress message

The different constraints regarding the electricity DSO can be considered:

The energy price as well as the feed-in tariff of a DSO can be provided as a time series (see Time series: time_series folder)
Peak demand pricing can be considered
The transformer station limitation can, but does not have to, be added.

FUN-MVS-09 - Load profiles¶

Description: The MVS model shall be provided with annual electric/thermal demand profiles (hourly values) for each load in the LES.
Rationale: Information necessary for building the MVS Multi-vector Model.
Priority: HIGH
Progress: Done
Progress message

The MVS can be provided with a variable number of energy consumption profiles, that can be connected to variable busses. Details on how this works can be found in these instructions.

FUN-MVS-10 - DH cost model¶

Description: For calculations involving district heating, the MVS model shall support data on thermal distribution network supply, concerning: a) kWh prices (both import and export from/to the grid), b) kWh/h prices (time series of prices), c) optional: thermal power cap (e.g. maximum allowable feed-in per day)
Rationale: Information necessary for building the MVS Multi-vector Model.
Priority: HIGH
Progress: Done
Progress message: Same as for FUN-MVS-08 - Electricity cost model.

FUN-MVS-11 - PV data¶

Description: For calculations involving PV assets, the MVS model shall be provided with data on PV assets: a) At minimum: Precise location (latitude and longitude), b) Optionally: performance indicators for new PV systems (efficiency - constant or time series, module technology, performance ratio), historical/tracked data (energy generated by existing PV systems, weather data), Inverter efficiency
Rationale: Information necessary for building the MVS Multi-vector Model.
Priority: HIGH
Progress: Done for option (b), no automization (minimal requirement met)
Progress message

To simulate a PV plant, the MVS model requires following data from the end-user:

(Historical) Specific PV generation profile (in kWh/kWp)
Inverter efficiencies can be considered with an additional energyConversion asset

ToDo

To ease the data input for the end-user, more processing could be included here (option a)). For example, the feedinlib could be used to fetch the specific PV generation profiles with following data:

Longitude and latitude
Module or efficiency
Performance ratio

This could also be implemented in the EPA.

FUN-MVS-12 - Battery data¶

Description: For calculations involving battery assets, the MVS model shall be provided with data on Battery Energy Storage Systems (BESS): a) Battery type (e.g. lead-acid, lithium ion) b. Technical parameters: C-rate, max and min state of charge (SOC), max. depth of discharge (DOD), roundtrip efficiency (constant or time series), c. Inverter efficiency (optional), d. historical/tracked data from existing BESS
Rationale: Information necessary for building the MVS Multi-vector Model.
Priority: HIGH
Progress: Done for option (b), no default inputs, no historical data (minimal requirement met)
Progress message

For the MVS, the type of the BESS does not matter. Important are the technical parameters:

C-rate
Maximum and minimum state of charge (SOC), whereas the latter is inverse to the maximum depth of discharge (DOD)
Charge- and discharge (constant or time series, equivalent to roundtrip-efficiency) as well as self-discharge rate (comp. efficiency)
It is possible to define soc_initial, the initial storage charge at the beginning of the optimization period, which is most important for short-term optimizations.
An inverter or charge controller can be defined by defining an additional energyConversion asset

Notes

It may be preferrable for the end-users to have default input values for different battery types (option a)), which is not implemented. This would best be addressed in the EPA with a database of default values, but is currently not being discussed.

Historical dispatch data of batteries is not considered, as the MVS is supposed to determine the optimal dispatch rather then only the performance of a current energy system with determined operational schedules.

FUN-MVS-13 - CHP data¶

Description: For calculations involving CHP assets, the MVS model shall be provided with efficiency factors (electric/thermal)
Rationale: Information necessary for building the MVS Multi-Vector Model.
Priority: LOW
Progress: In progress (minimal requirement met)
Progress message

A simple CHP model is already included in the MVS (compare Condensing power plants and Combined heat and power (CHP)). It considers a fix ratio between thermal and electric output.

ToDo

For a variable ratio between heat and electricity output, a new, specific oemof asset would need to be added to the MVS.

FUN-MVS-14 - Thermal storage data¶

Description: For calculations involving Thermal Storage assets, the MVS model shall be provided with: a) Charging and discharging efficiencies, b. Max/Min SOC, initial SOC
Rationale: Information necessary for building the MVS Multi-Vector Model.
Priority: LOW
Progress: Done
Progress message

It is possible to simulate thermal storage assets with the MVS. Their model is analogous to the BESS, which fulfills the requirement. They are defined by:

C-rate
Maximum and minimum state of charge (SOC)
Charge- and discharge (constant or time series, equivalent to roundtrip-efficiency) as well as self-discharge rate (comp. efficiency)
It is possible to define soc_initial, the initial storage charge at the beginning of the optimization period, which is most immportant for short-term optimizations.

Adding another level of detail, it is possible to model a Stratified thermal energy storage, with additional parameters fixed_thermal_losses_relative and fixed_thermal_losses_absolute.

FUN-MVS-15 - Autonomous operation data¶

Description: The MVS model shall be provided with information on the autonomous operation of the LES i.e. minimum/maximum time of autonomy for specific time intervals.
Rationale: Information necessary for building the MVS Multi-vector Model
Priority: HIGH
Progress: Done
Progress message

This requirement is addressed by the degree of autonomy constraint. It is related to the aggregated demand of the energy system and the required consumption from the grid (comp. DOA), and not minimum or maximum time of autonomous operation.

Notes

A constraint of time-related autonomous operation is not possible in the current MVS, as it would introduced a mixed-integer constraint, which would extend simulation times too much. It would be possible in the future to add KPI that quantify the behaviour.

FUN-MVS-16 - Economic data¶

Description: The MVS model shall be provided with information on economic assumptions per asset: CAPEX/kW and OPEX/kWh (constant or time series), lifetime (years), Weighted Average Cost of Capital (WACC).
Rationale: Information necessary for building the Multi-vector Model.
Priority: HIGH
Progress: Done
Progress message

The MVS receives economic data from the end-user. This includes:

FUN-MVS-17 - Constraints¶

Description: The MVS model shall be provided with constraints of the optimisation problem: a) Operating reserve provided by the battery (i.e. redundancy, availability), b. Sizing constraints, c. Cost constraints
Rationale: Information necessary for building the Multi-vector Model.
Priority: HIGH
Progress: In progress
Progress message

To address the sizing constraint, the attribute maximumCap was introduced. This will limit the optimized capacity, even if this results in higher energy supply costs.

A cost constraint is for now disregarded, as always the cheapest supply solution is identified. Limiting the overall NPC would result in infeasible solutions and a termination of the MVS. Cost constraints considering specific technologies can be covered by adapting the maximumCap.

ToDo

It was decided at the beginning of the project that the operating reserve constraint may be developed in cooperation with the end-users. This constraint would still need to be defined with the stakeholders.

Non-Functional Requirements¶

NF-MVS-01 - MVS pre-processing tools for LES optimization model input¶

Description: The MVS should support Python-Pandas DataFrames as parameterization input for the LES model
Scope: Interface, Usability
Metric: Y/N
Verification and Measurement: The requirement is validated by observing the system under test when an operator attempts to input/modify the model parameters.
Target: User can adjust input parameters without any further support
Progress: Done
Progress message

Internally, the MVS uses dictionaries (dict) in combination with pandas (pd.DataFrame) to set up the energy system model. However, for data exchange with the end-user the input files, ie. the csv or json file is essential. To be able to use all features of the MVS, the user should consider the terminal-based MVS with csv input files. For a more comfortable and interactive usage, the end user can use the MVS though the user interface of the Energy Planning Application (EPA). Here, the data format becomes irrelevant for the user.

NF-MVS-02 - MVS post-processing tools for LES optimization model output/results¶

Description: The MVS should provide results aggregation, reports, and plots
Scope: User Interface, Usability
Metric: Y/N
Verification and Measurement: The requirement is validated by observing the system under test when an operator attempts to access the output results.
Target: User can extract the results in a way that can be directly used for the users purpose
Progress: Done
Progress message

The post-processing of results ensures that important KPI can be provided for the energy system optimization. There are three output formats of the MVS:

For the end-user of the standalone application, an automatic report is generated that makes scenario evaluation easy
For a developer of the standalone application, the results are also provided as excel files and pngs
For the EPA, the results are provided in a json format to be displayed interactively in their environment

Notes

Improving the outputs is a continuing task. Following improvements can be considered in the future:

Move all KPI connected to the individual energy vectors into a seperate table and display in the report
Add-on requested by end-users: Cash flow projections

NF-MVS-03 - Communication interface between MVS and ESB¶

Description: Communication functionality must be included so that ESB can send requests to MVS and vice versa. This assures that all requests can be coordinated through one platform (e.g. ESB).
Scope: User Interface, Usability
Metric: Y/N
Verification and Measurement: Send a set of different requests from ESB to MVS and count received requests. Do vice versa.
Target: Send/receive requests that can be processed without information loss
Progress: Done
Progress message

After discussion, there is no direct interface of the ESB and the MVS. The MVS is a standalone application that must be usable without the ESB. To ease end-user use, the EPA (Energy Planning Application) is developed. It sends inputs in json format to the MVS, and receives a json file with the results back. Parsers are coded to allow a translation of the different formats of the MVS and the EPA.

Notes

The EPA development is a continuous process, and currently the MVS has more features than the EPA. Mainly, the EPA does not feature:

Any constraints of the MVS
GHG emission calculation
Set of energy assets of different energy vectors (as EPA explicitly names the assets)

NF-MVS-04 - Unit commitment time step restriction¶

Description: Energy flows between selected components (Unit commitment) are simulated in hourly timesteps.
Scope: Performance
Metric: Timestamps
Verification and Measurement: Subtract 2-time steps.
Target: Timestep width of 1 hour
Progress: Done
Progress message: The MVS can be run for a variable number of days. The time series have to be provided on an hourly basis.
Notes: A wish from the end-users war a finer resolution of eg. 15-minute time steps. This possibility still has to be explored.

NF-MVS-05 - Interface for technical parameters and model¶

Description: Technical parameters are reflected in component modelling
Scope: Performance
Metric: Technical variable in energy system model object
Verification and Measurement: Technical variable in ESM object being not NAN.
Target: N/A
Progress: Done
Progress message: The MVS uses the input parameters to compile the component models. This is also tested using pytests and benchmark tests.

NF-MVS-06 - Interface for economic parameters and model¶

Description: Cost parameters are reflected in component modelling
Scope: Interface
Metric: Cost variable in energy system model object
Verification and Measurement: Cost variable in ESM object being not NAN.
Target: N/A
Progress: Done
Progress message

The MVS uses the input parameters to compile the component models. This is also tested using pytests and benchmark tests.