The presented paper implements three exemplary adapters to connect OS with

a custom EMS client that implements OS in a cosimulation scenario,

General Learning Evolutionary Algorithm and Method (GLEAM), an evolutionary optimization algorithm,

and Monte Carlo, a random sampling algorithm for development purposes.
GLEAM is an evolutionary algorithm that has proven to be efficient in scheduling tasks. All adapters use Redis^{Footnote 2} as communication infrastructure.
Domain knowledge regarding ESs is implemented into the job data class, the BCs, and the domain mapping functions (compare Fig. 2), before implemented adapters interact. The implemented domain knowledge is based on Geidl and Andersson (2007)’s EH work. EH is one generic way of describing ESs.
Since EH is a generic concept for mathematical description, implemented domain knowledge does not restrict OS appliance to specific compositions of ESs, ensuring the system’s flexibility.
Converters and storages are controllable units that condition, transform, or store energy, whereas forecasts (sometimes called generic/active consumer) are any noncontrollable generations or loads. The combination of the three facility types allows a general description of any composition of ESs.
EH further allows the implementation of topological connections between facilities. The most basic topological arrangement of EH components is the connection of any energy carrier to a grid. The grid connections do not restrict the EH components in consumption or generation. Consequences of certain facilities’ consumption or generation must be considered in the objective function, e.g., by a high price of energy carrier grid. The presented implementation uses these simplified topological assumptions.
Data interfaces
Implemented data interfaces are separated into four classes: job data, optimization suggestions, objective value, and optimization results (Compare Figs. 2 and 4).
The job data consists of two subclasses: setup and entity. The setup data interface is shown in Listing 1 and provides all data needed to initialize and set up the optimization process, including initialization parameters for the optimization problem, static information regarding the simulation system, or the number of objective values returned after evaluation.

First, the number of different facilities \(number\_facilities\) that expect schedules is described as an integer. The \(power\_fraction\) represents the range for each set point. Typically the range is [0, 1] for converter units and \([1,1]\) for storage units. The \(power\_fraction\) is implemented as a dictionary with the keys representing the names of the entities. \(start\_time\) and \(stop\_time\) are integers representing the internal time for the start and stop of the optimization.

Next, the socalled sitting variables implement \(interval\_steps\) as the number of set points that assemble one schedule. The \(names\_facilities\) is a list of all facility names, including forecasts being not part of the optimization. All names used as keys in the \(power\_fraction\) must be listed here. The difference between \(stop\_time\ \ start\_time\) represents the optimization time range \(calculation\_time\). The \(interval\_time\) describes the time between two optimization steps. In the current implementation, all set points have to be equidistant. Further research on nonequidistant ES scheduling is currently taking place based on the novel architecture.

The third group consists of the objective functions and the constraints. Each objective function is given a representative name in a list \(obj\_functions\). The same applies to the constraints.
The second subclass entity is the data class regarding data modeling of facilities and is shown in Listing 2. All later implemented BCs rely on the respective entity data objects. The parent class entity consists of a name, controlling that flags whether the entity can receive schedules from the optimization algorithm, the outputs that the relative facility has, and the Lookup Table (LUT) with a link for later domain mapping.
Based on EH work, entities are further divided into three subclasses implementing respective metadata for each. Converters are described by \(P\_min\), the minimal power, the maximal power \(P\_max\), the current power \(P\_0\), and the maximal power increase RampRate.
Storage units additionally use parameters for calculating the current energy of the facility. \(E\_max\) is the maximum energy, the current energy \(E\_0\), the minimal energy \(E\_min\), and the efficiency term Eta.
Forecasts are not controllable facilities based purely on timeseries data. As they receive no schedules, they do not need any metadata description.
An optimization suggestion contains one schedule per controllable instance. The evaluation of one optimization suggestion is stored in the goal value data class.
Based on previously discussed data interfaces, the actual evaluation of schedule suggestions takes place, starting with the BC.
Boundary conditions
For readability, the implemented BCs are presented in mathematical syntax. Exemplary consider the BC that conditions for the minimal power output of a converter unit. The power output \(P^i_\alpha (t)\) of an entity i and an energy carrier \(\alpha\) at a given time point t are described by the nominal setpoint \(s^i(t)\) times the maximal power output. This power output has to be greater or equal to a minimal power \(P^i_{\alpha ,min}\). If not, the converter unit shuts down, producing an output of \(0\cdot P_{\alpha ,max}^i\).
$$\begin{aligned} P^i_{\alpha }(t) = s^i(t) \cdot {P_{\alpha ,max}^i} \ge P^i_{\alpha ,min}. \end{aligned}$$
(1)
For this explicit BC, two variables have to be provided in the metadata: \(P_{\alpha ,max}^i\) and \(P^i_{\alpha ,min}\). The actual condition can be implemented when both variables are presented in the converter instance. All boundaries are rearranged to mathematically condition the setpoint \(s^i(t)\). The presented BC that reviews \(P^i_{\alpha ,min}\) is formulated as
$$\begin{aligned} s^i(t)= {\left\{ \begin{array}{ll} 0,&{} \text {if } s^i(t) \le \frac{P^i_{\alpha ,min}}{P_{\alpha ,max}^i}\\ s^i(t), &{} \text {otherwise}. \end{array}\right. } \end{aligned}$$
(2)
Additionally BC for \(P_{max}\)
$$\begin{aligned} s^i(t)= {\left\{ \begin{array}{ll} \frac{P^i_{\alpha ,max}}{P_{\alpha ,max}^i},&{} \text {if } s^i(t) \ge \frac{P^i_{\alpha ,max}}{P_{\alpha ,max}^i} \\ s^i(t), &{} \text {otherwise}, \end{array}\right. } \end{aligned}$$
(3)
and RampRate
$$\begin{aligned} s^i(t)= {\left\{ \begin{array}{ll} s^i(t\Delta t) + \frac{\Delta P_{\alpha ,max}^i}{P_{\alpha ,max}^i},&{} \text {if } s^i(t) \ge s^i(t\Delta t) + \frac{\Delta P_{\alpha ,max}^i}{P_{\alpha ,max}^i} \\ s^i(t\Delta t)  \frac{\Delta P_{\alpha ,max}^i}{P_{\alpha ,max}^i},&{} \text {if } s^i(t) \le s^i(t\Delta t)  \frac{\Delta P_{\alpha ,max}^i}{P_{\alpha ,max}^i} \\ 0, &{} \text {otherwise}, \end{array}\right. } \end{aligned}$$
(4)
are added to describe a converter facility. Storage units apply the same BC as converter, \(P\_min\) though changes to
$$\begin{aligned} s^i(t)= {\left\{ \begin{array}{ll} \frac{P^i_{\alpha ,min}}{P_{\alpha ,max}^i},&{} \text {if } s^i(t) \le \frac{P^i_{\alpha ,min}}{P_{\alpha ,max}^i} \\ s^i(t), &{} \text {otherwise}. \end{array}\right. } \end{aligned}$$
(5)
Additionally BC for energy of a storage facility E is added as
$$\begin{aligned} s^i(t)= {\left\{ \begin{array}{ll} s^i(t\Delta t) + \frac{\Delta P_{\alpha ,max}^i}{P_{\alpha ,max}^i},&{} \text {if } s^i(t) \ge s^i(t\Delta t) + \frac{\Delta P_{\alpha ,max}^i}{P_{\alpha ,max}^i} \\ s^i(t\Delta t)  \frac{\Delta P_{\alpha ,max}^i}{P_{\alpha ,max}^i},&{} \text {if } s^i(t) \le s^i(t\Delta t)  \frac{\Delta P_{\alpha ,max}^i}{P_{\alpha ,max}^i} \\ 0, &{} \text {otherwise}. \end{array}\right. } \end{aligned}$$
(6)
Forecasts are not subject to any BCs. The principle of BCs leaves room for future applications of forecast calculations like uncertainty.
The mapping is currently separated into two functions:

Interpolation based on LUT for all three types of entities, and

integration of the setpoint to gain a state of charge of storage units.
Literature suggests other approaches that can be integrated as additional functions here.
Objective functions
Implemented Objective Functions are oriented on three of the most common functions in literature: minimization of 1) system operational cost, 2) emissions, and 3) deviation from original demand. For the ability to optimize multiple functions collectively, all functions are connected through a penalty variable. The penalty variable for each function is selected so that the resulting unit is priced in euros. In general, both system’s operational cost and system emission minimizations are the same, as they punish an energy or mass flow with a price \(p_\alpha\) resulting in the initialization of operational cost.
$$\begin{aligned} c_{operational} = \sum _t \sum _i \sum _\alpha P^i_\alpha (t) \cdot p_\alpha (t). \end{aligned}$$
(7)
It is common in the literature to separate the emission and operational costs.
The minimization of system operational costs is formulated as the sum over all time steps t, the entity’s i and energy carriers \(\alpha\)
$$\begin{aligned} {\begin{matrix} c_{operational} &{}= \sum _t c_{operational}(t) \\ &{} = \sum _t \sum _i \sum _\alpha P^i_\alpha (t) \cdot p_\alpha (t), \end{matrix}} \end{aligned}$$
(8)
with \(P^i_\alpha (t)\) the power flow of an entity i and an energy carrier \(\alpha\), and \(p_\alpha\) the price of an energy carrier \(\alpha\).
In the same way, the total cost of emission is phrased as
$$\begin{aligned} {\begin{matrix} c_{CO2} &{}= \sum _t c_{CO2}(t) \\ \ &{}= \sum _t \dot{m}_{CO2}(t) \cdot p_{CO2}(t). \end{matrix}} \end{aligned}$$
(9)
Last, the deviation from the original demand is integrated quadratic in order to account for the sign of \(P^i_\alpha\) as
$$\begin{aligned} {\begin{matrix} d_{dev} &{}= \sum _t \left( P^{dev}(t) \right) ^2 \\ \ &{}= \sum _t \sum _i \sum _\alpha \left( P^{i}_{\alpha }(t)\right) ^2. \end{matrix}} \end{aligned}$$
(10)