Future Developments#
This section outlines potential future enhancements to the optimisation model, based on a number of identified challenges and opportunities for more detailed modelling. These items represent a roadmap for increasing the model’s accuracy and applicability to real-world scenarios.
To-Do List#
The following is a list of key areas for future development, divided into modelling enhancements and computational/structural improvements.
Modelling Enhancements#
This category includes improvements that add new features, constraints, or more detailed representations of physical or financial systems to the model.
Sequential Market Participation:
Challenge: The current model does not fully capture the sequential nature of day-ahead (DA), intraday (ID), and imbalance (IMB) markets. It assumes perfect foresight for intraday markets.
To-Do: Implement a deterministic MILP model that can handle the sequential decision-making process across these markets. This could involve a rolling horizon approach or the use of penalty factors to represent the uncertainty of intraday prices.
Prototype Equations: The objective function would be expanded to include revenues and costs from each market stage:
\[\max \pi = \sum_{t \in T} (R_{DA,t} + R_{ID,t} - C_{DA,t} - C_{ID,t})\]where bids in later markets adjust the position from earlier ones:
\[P_{dispatch,t} = B_{DA,t} + B_{ID,t}\]Potential Integration:
Introduce new decision variables in oM_ModelFormulation.py for bids in each market (e.g., \(vBidDA_t\), \(vBidID_t\)).
Add new parameters for the prices in each market.
Implement new constraints to link the market positions sequentially.
LER (Limited Energy Reservoir) Constraints Implementation:
Challenge: The model needs to incorporate the hysteresis logic for Normal/Alert Energy Management (NEM/AEM) for BESS participating in Frequency Containment Reserve (FCR) markets, as per Swedish TSO requirements.
To-Do: Implement the state-dependent enable/disable logic for NEM/AEM activation states using binary variables and state transition constraints.
Prototype Equations: The hysteresis logic can be modelled using Big-M constraints. For example, for the NEM-low mode activation:
\[SOC_t - SOC_{lower,enable} \leq M \cdot (1 - b_{NEM-low,t})\]\[SOC_{lower,disable} - SOC_t \leq M \cdot b_{NEM-low,t}\]Potential Integration:
Add new binary variables in oM_ModelFormulation.py for each NEM/AEM state (e.g., \(vNEM_{low,t}\)).
Define new parameters for the SOC thresholds (e.g., \(pSOC_{lower,enable}\)).
Add the Big-M constraints to create_constraints in oM_ModelFormulation.py.
PPA Inclusion in the Model:
Challenge: The model currently lacks the functionality to incorporate a virtual Power Purchase Agreement (PPA) or a Contract for Difference (CfD) into the financial model and technical constraints.
To-Do: Develop the necessary mathematical formulations to represent the financial settlements of a virtual PPA and integrate them into the objective function.
Prototype Equation: The trading revenue from a two-way CfD can be formulated as:
\[R_{trad,t} = (p_{market,t} - p_{strike}) \cdot B_{PPA,t}\]Potential Integration:
Modify the objective function in oM_ModelFormulation.py to include this revenue component.
Add a new parameter for the PPA strike price (\(pPPA_{strike}\)) and a variable for the PPA volume (\(vPPA_{volume,t}\)).
Multiple Timescales Modeling:
Challenge: The model needs to handle both high-resolution frequency regulation signals (second/minute-level) and energy market data (hour-level) simultaneously.
To-Do: Investigate and implement the best time resolution to handle both frequency and energy markets, potentially using time-aggregation techniques.
Prototype Equation: This is primarily a structural change. Equations would need to be defined over different time sets, for example energy balance over hourly steps \(t\) and FCR provision over minute-steps \(\tau\):
\[E_{balance,t} = ...\]\[P_{FCR, \tau} = ...\]Potential Integration:
Requires a significant change to the temporal structure in oM_InputData.py to handle multiple time resolutions.
All time-indexed variables and constraints in oM_ModelFormulation.py would need to be updated to use the appropriate time sets.
Market Participation Exclusion Rules:
Challenge: The model uses a Big-M formulation to allow flexible participation in multiple frequency services, but it does not yet incorporate specific exclusion rules that may be imposed by TSOs (e.g., for Swedish frequency markets).
To-Do: Implement the necessary logical constraints to enforce any exclusion rules between different frequency services, such as FCR-N and aFRR.
Prototype Equation: Mutual exclusivity can be enforced with a simple linear constraint on the binary participation variables:
\[b_{FCR-N,t} + b_{aFRR,t} \leq 1\]Potential Integration:
Add this new constraint to create_constraints in oM_ModelFormulation.py, linking the existing binary variables for market participation.
Grid Fees and COMA Costs:
Challenge: The model’s cost structure for grid usage and operations is not yet fully defined.
To-Do: Define and implement a realistic cost structure for grid usage fees (MWh imported/exported) and COMA (Operating, Maintenance, Administration) costs, whether as fixed annual costs or usage-based.
Prototype Equations: These costs would be added to the objective function:
\[C_{grid,t} = c_{grid,import} \cdot P_{import,t} + c_{grid,export} \cdot P_{export,t}\]\[C_{COMA} = C_{fixed\_O\&M}\]Potential Integration:
Update the objective function in oM_ModelFormulation.py.
Add new parameters for the grid fee rates (\(pGridFee_{import}\)) and fixed O&M costs (\(pCOMA_{cost}\)).
The grid cost would use the existing variables for grid import/export (\(vElecImport_t\), \(vElecExport_t\)).
Vehicle-to-Grid (V2G) Integration:
Current Status: The model currently includes a basic representation of an aggregated EV fleet, considering it as a flexible load and storage resource with AC charging capabilities.
Challenge: The existing model can be enhanced to provide a more detailed and realistic representation of V2G by incorporating different charging technologies (DC), considering battery degradation from cycling, and modelling more complex driver behaviours.
To-Do: Extend the V2G model to include DC fast-charging capabilities, add a cost component for battery degradation, and refine the constraints related to driving energy requirements.
AC vs. DC Charging:
AC Charging (Implemented): The current model represents lower power charging via the vehicle’s onboard charger, using a single efficiency parameter (\(\eta_{AC}\)).
DC Charging (Future): A future extension would add high-power DC charging, which bypasses the vehicle’s onboard charger. This would require a separate, higher efficiency parameter (\(\eta_{DC}\)) and could be linked to different grid connection points or constraints.
Prototype Equations: The state of charge for the aggregated EV fleet will continue to use the existing formulation, but a degradation cost should be added to the objective function:
\[C_{V2G\_deg,t} = c_{deg} \cdot (P_{chg,t} + P_{dis,t})\]And the energy requirement constraint remains crucial:
\[SOC_{EV,t} \geq SOC_{min,driving,t}\]Potential Integration:
Modify the existing EV-related sets and parameters in oM_InputData.py to include data for DC chargers (e.g., efficiency, capacity).
Introduce a new cost term for degradation to the objective function in oM_ModelFormulation.py.
Add new variables or constraints if necessary to distinguish between AC and DC charging power, potentially allowing simultaneous connection to both if the model scope requires it.
Degradation Modeling for Energy Storage:
Challenge: To capture the long-term economic impact of operational decisions, the model must account for the physical degradation of storage assets. This is complex because different technologies degrade in different ways.
To-Do: Implement distinct degradation cost models for electrochemical batteries (BESS) and hydrogen systems (electrolyzers, fuel cells).
BESS Degradation (Electrical Storage): Battery degradation is primarily driven by two factors:
Cycle Aging: Caused by the throughput of energy (charging and discharging).
Calendar Aging: Occurs over time regardless of usage.
Simple Model: A linear cost per MWh of throughput is a common simplification for cycle aging.
\[C_{BESS\_deg,t} = c_{cycle} \cdot (P_{chg,t} + P_{dis,t}) + c_{calendar}\]Advanced Model: Depth of Discharge (DoD) Penalization - A more accurate approach recognizes that deeper discharge cycles cause more stress than shallow ones. This non-linear cost can be approximated in a linear model using a piecewise function.
Prototype Equation: The total degradation cost is the sum of costs incurred in different SOC segments, each with a different penalty.
\[C_{BESS\_cycle\_deg,t} = \sum_{s \in S} c_{segment,s} \cdot E_{discharged,s,t}\]where \(S\) is the set of DoD segments (e.g., 100-80%, 80-60%), \(c_{segment,s}\) is the increasing cost for each segment, and \(E_{discharged,s,t}\) is the energy discharged within that segment.
Potential Integration: This requires a more complex formulation, typically using Special Ordered Sets of Type 2 (SOS2) constraints or binary variables to model the piecewise cost function. New parameters would be needed in oM_InputData.py to define the segment breakpoints and costs.
Hydrogen System Degradation: Degradation in hydrogen systems primarily affects the conversion components, not the hydrogen storage tank itself. Key drivers include:
Operational Stress: Total operating hours for electrolyzers and fuel cells.
Start/Stop Cycles: Thermal and mechanical stress from starting up and shutting down.
Prototype Equations for Hydrogen Systems:
\[C_{Hyd\_deg,t} = c_{op} \cdot b_{commit,t} + c_{su} \cdot b_{startup,t}\]where \(b_{commit,t}\) is a binary variable for being online and \(b_{startup,t}\) is a binary for starting up at time \(t\).
Potential Integration:
Add new parameters to oM_InputData.py for degradation cost factors (e.g., \(pBESS_{cycle\_cost}\), \(pHyd_{op\_cost}\)).
Add these new cost components to the objective function in oM_ModelFormulation.py, linking them to existing variables for power dispatch and commitment status.
Computational and Structural Enhancements#
This category focuses on improvements to the underlying code structure and mathematical formulation to enhance computational efficiency, scalability, and maintainability.
Code Restructuring with Python Classes:
Challenge: The current implementation relies on a procedural approach with functions spread across multiple modules. This can make the code harder to navigate, debug, and extend as the model complexity grows.
To-Do: Refactor the codebase into a more object-oriented structure. A central OptimizationModel class could encapsulate the data, Pyomo model, and methods for building, solving, and post-processing.
Benefits:
Encapsulation: Grouping related data and functions into a single class improves organization.
Maintainability: Changes to the model are localized within the class, reducing the risk of unintended side effects.
Scalability: A class-based structure is easier to extend with new components (e.g., new assets, new market products).
Potential Integration:
Create a new class in a module like oM_ModelClass.py.
Methods of this class would wrap the existing functions from oM_ModelFormulation.py, oM_InputData.py, etc.
The main script el1xr_Main.py would then instantiate this class to run the optimisation.
Modular Component Implementation with Pyomo Blocks:
Challenge: As more assets (like V2G, electrolyzers, different PPA types) are added, the main model formulation in create_constraints can become monolithic and difficult to manage. Adding or removing a component requires manually editing a large function.
To-Do: Use Pyomo’s Block feature to encapsulate the variables and constraints for each physical or financial component. Each block would represent a self-contained model of an asset.
Example: A BESS block could contain all variables (state of charge, charge/discharge power) and constraints (energy balance, power limits) related to the battery.
Benefits:
Modularity: Makes it easy to add, remove, or swap different implementations of a component (e.g., a simple BESS model vs. an advanced one with degradation).
Readability: The main model becomes a cleaner composition of these blocks, rather than a long list of constraints.
Scalability: Simplifies the management of models with many individual assets of the same type (e.g., multiple battery units).
Potential Integration:
In oM_ModelFormulation.py, define a separate function for each component that returns a Block (e.g., def create_bess_block(…)).
The main create_constraints function would then call these functions to attach the blocks to the main model.