mirror of
https://github.com/Akkudoktor-EOS/EOS.git
synced 2025-10-29 13:56:21 +00:00
259 lines
11 KiB
Markdown
259 lines
11 KiB
Markdown
|
|
% SPDX-License-Identifier: Apache-2.0
|
|||
|
|
(resource-page)=
|
|||
|
|
|
|||
|
|
# Resources (Device Simulations)
|
|||
|
|
|
|||
|
|
## Concepts
|
|||
|
|
|
|||
|
|
The simulations for resources are leaning on general concepts of the [S2 standard].
|
|||
|
|
|
|||
|
|
### Control Types
|
|||
|
|
|
|||
|
|
The control of resources and such what a resource simulation will simulate follows three
|
|||
|
|
basic control principles:
|
|||
|
|
|
|||
|
|
- Operation Mode Based Control (OMBC)
|
|||
|
|
- Fill Rate Based Control (FRBC)
|
|||
|
|
- Demand Driven Based Control (DDBC)
|
|||
|
|
|
|||
|
|
Although these control principles differ enough to separate them into three distinct control types,
|
|||
|
|
there are some common aspects that make them similar:
|
|||
|
|
|
|||
|
|
- Operation Modes
|
|||
|
|
- Transitions and
|
|||
|
|
- Timers.
|
|||
|
|
|
|||
|
|
The objective for a control type is under which circumstances what things can be adjusted, and what
|
|||
|
|
the constraints are for these adjustments. The three control types model a virtual, abstract resource
|
|||
|
|
for simulation.
|
|||
|
|
|
|||
|
|
The abstract resource ignores all details of pyhsical device that are not relevant to energy
|
|||
|
|
management. In addition, physical devices have an enormous variety in parameters, sensors, control
|
|||
|
|
strategies, concerns, safeguards, and so on. It would be practically impossible to develop a
|
|||
|
|
simulation that can
|
|||
|
|
understand all the parameters of all the physical devices on the market. By making the resource more
|
|||
|
|
abstract, its concepts can be translated to all sorts of physical devices, even though internally
|
|||
|
|
they function very differently. As a consequence, it not always possible to make a 100% accurate
|
|||
|
|
description of all the behaviors and constraints in these abstractions. But the abstractions used
|
|||
|
|
in the control types are quite powerful, and should allow you to come pretty close.
|
|||
|
|
|
|||
|
|
The control types basically define how the simulated resource can be described. The user in the end
|
|||
|
|
selects the proper desciption of a physical device using the configuration options provided for
|
|||
|
|
resource simulations. The configuration sets how the simulated resource functions, what it can do and
|
|||
|
|
what kind of constraints it has.
|
|||
|
|
|
|||
|
|
### Resource Simulation
|
|||
|
|
|
|||
|
|
Based on the description of this virtual resource, the resource simulation can make predictions of
|
|||
|
|
what the physical device will do in certain situations, and when it is allowed to execute
|
|||
|
|
instructions generated by the optimization as part of the energy management plan evaluation.
|
|||
|
|
|
|||
|
|
### Resource Status
|
|||
|
|
|
|||
|
|
Once the physical device has changed it's behavior, the resource simulation should be informed
|
|||
|
|
to make the simulation change it's state accordingly.
|
|||
|
|
|
|||
|
|
The actual state of a pyhsical device may be reported to the resource simulation by the
|
|||
|
|
**PUT** `/v1/resource/status` API endpoint.
|
|||
|
|
|
|||
|
|
## Battery
|
|||
|
|
|
|||
|
|
There is a wealth of possible battery operation modes:
|
|||
|
|
|
|||
|
|
<!-- pyml disable line-length -->
|
|||
|
|
| Mode | Purpose / Behavior | Typical Trigger / Context |
|
|||
|
|
| ------------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
|
|||
|
|
| **IDLE** | Battery neither charges nor discharges (SOC stable). | No active control objective or power imbalance below thresholds. |
|
|||
|
|
| **SELF_CONSUMPTION** | Charge from PV surplus and discharge to cover local load. | PV generation > load (charge) or load > PV (discharge). |
|
|||
|
|
| **NON_EXPORT** | Charge from on-site or local surplus with the goal of minimizing or preventing energy export to the external grid. Discharging to the grid is not allowed. | Export limit reached and SOC < SOC_max. |
|
|||
|
|
| **PEAK_SHAVING** | Discharge to keep grid import below a target threshold. | Predicted or measured site load exceeds peak limit. |
|
|||
|
|
| **GRID_SUPPORT_EXPORT** | Discharge energy to grid for revenue (V2G, wholesale market, flexibility service). | Market or signal permits profitable export. |
|
|||
|
|
| **GRID_SUPPORT_IMPORT** | Charge from grid to absorb surplus or provide up-regulation service. | Low-price or grid-support signal detected. |
|
|||
|
|
| **FREQUENCY_REGULATION** | Rapid charge/discharge response to grid frequency deviations. | Active participation in frequency control. |
|
|||
|
|
| **RAMP_RATE_CONTROL** | Smooth site-level power ramp rates by buffering fluctuations. | Sudden PV/load change exceeding ramp limit. |
|
|||
|
|
| **RESERVE_BACKUP** | Maintain SOC ≥ reserve threshold to ensure backup capacity. | Resilience mode active, grid operational. |
|
|||
|
|
| **OUTAGE_SUPPLY** | Islanded operation: power local loads using stored energy (and PV if available). | Grid failure detected. |
|
|||
|
|
| **FORCED_CHARGE** | Manual or external control command to charge (e.g., pre-event, maintenance). No discharge. | Operator or optimizer command. |
|
|||
|
|
| **FORCED_DISCHARGE** | Manual or external control command to discharge. No charge. | Operator or optimizer command. |
|
|||
|
|
| **FAULT** | Battery unavailable due to fault, safety, or protection state. | Fault detected (thermal, voltage, comms, etc.). |
|
|||
|
|
<!-- pyml enable line-length -->
|
|||
|
|
|
|||
|
|
The optimization algorithm, the device simulation and the configuration properties only support the
|
|||
|
|
most important of these modes.
|
|||
|
|
|
|||
|
|
### Battery Simulation
|
|||
|
|
|
|||
|
|
The battery simulation assumes an idealized battery model. Under this model, the battery can be
|
|||
|
|
operated in three discrete operation modes with fill rate based control (FRBC):
|
|||
|
|
|
|||
|
|
| **Operation Mode ID** | **Description** |
|
|||
|
|
| ------------------------ | --------------------------------------------------------------------- |
|
|||
|
|
| **SELF_CONSUMPTION** | Charge from local surplus and discharge to cover local load. |
|
|||
|
|
| **NON_EXPORT** | Charge from local surplus and do not discharge. |
|
|||
|
|
| **FORCED_CHARGE** | Charge. |
|
|||
|
|
|
|||
|
|
The **operation mode factor** (0.0–1.0) specifies the normalized power rate relative to the
|
|||
|
|
battery's nominal maximum charge or discharge power. A value of 1.0 corresponds to full-rate
|
|||
|
|
charging or discharging, while 0.0 indicates no power transfer. Intermediate values scale the power
|
|||
|
|
proportionally.
|
|||
|
|
|
|||
|
|
The **fill level** (0.0–1.0) specifies the normalized fill level relative to the
|
|||
|
|
battery's nominal maximum charge. A value of 1.0 corresponds to full while 0.0 indicates empty.
|
|||
|
|
Intermediate values scale the fill level proportionally.
|
|||
|
|
|
|||
|
|
### Battery Configuration
|
|||
|
|
|
|||
|
|
### Battery Stati
|
|||
|
|
|
|||
|
|
To keep the battery simulation in synchonization with the actual stati of the battery the following
|
|||
|
|
resource stati may be reported to EOS by the **PUT** `/v1/resource/status` API endpoint.
|
|||
|
|
|
|||
|
|
#### Battery FRBCActuatorStatus
|
|||
|
|
|
|||
|
|
The operation mode the battery is currently operated.
|
|||
|
|
|
|||
|
|
```json
|
|||
|
|
{
|
|||
|
|
"type": "FRBCActuatorStatus",
|
|||
|
|
"active_operation_mode_id": "GRID_SUPPORT_IMPORT",
|
|||
|
|
"operation_mode_factor": "0.375",
|
|||
|
|
"previous_operation_mode_id": "SELF_CONSUMPTION",
|
|||
|
|
"transistion_timestamp": "20250725T12:00:12"
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
#### Battery FRBCStorageStatus
|
|||
|
|
|
|||
|
|
The current battery state of charge (SoC).
|
|||
|
|
|
|||
|
|
```json
|
|||
|
|
{
|
|||
|
|
"type": "FRBCStorageStatus",
|
|||
|
|
"present_fill_level": "0.88"
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
#### Battery PowerMeasurement
|
|||
|
|
|
|||
|
|
The current power that the battery is charged or discharged with \[W\].
|
|||
|
|
|
|||
|
|
```json
|
|||
|
|
{
|
|||
|
|
"type": "PowerMeasurement",
|
|||
|
|
"measurement_timestamp": "20250725T12:00:12",
|
|||
|
|
"values": [
|
|||
|
|
{
|
|||
|
|
"commodity_quantity": "ELECTRIC.POWER.L1",
|
|||
|
|
"value": "887.5"
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"commodity_quantity": "ELECTRIC.POWER.L2",
|
|||
|
|
"value": "905.5"
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"commodity_quantity": "ELECTRIC.POWER.L2",
|
|||
|
|
"value": "1100.7"
|
|||
|
|
},
|
|||
|
|
]
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
For symmetric (or unknown) power distribution:
|
|||
|
|
|
|||
|
|
```json
|
|||
|
|
{
|
|||
|
|
"type": "PowerMeasurement",
|
|||
|
|
"measurement_timestamp": "20250725T12:00:12",
|
|||
|
|
"values": [
|
|||
|
|
{
|
|||
|
|
"commodity_quantity": "ELECTRIC.POWER.3_PHASE_SYM",
|
|||
|
|
"value": "1000"
|
|||
|
|
}
|
|||
|
|
]
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## Electric Vehicle
|
|||
|
|
|
|||
|
|
The electric vehicle is basically a battery with a reduced set of operation modes.
|
|||
|
|
|
|||
|
|
### Electric Vehicle Instructions
|
|||
|
|
|
|||
|
|
The electric vehicle control instructions assume an idealized EV battery model. Under this model,
|
|||
|
|
the EV battery can be operated in two operation modes:
|
|||
|
|
|
|||
|
|
| **Operation Mode ID** | **Description** |
|
|||
|
|
| --------------------- | ----------------------------------------------------------------------- |
|
|||
|
|
| **IDLE** | Battery neither charges nor discharges; holds its state of charge. |
|
|||
|
|
| **FORCED_CHARGE** | Charge at a specified power rate up to the allowable maximum. |
|
|||
|
|
|
|||
|
|
The **operation mode factor** (0.0–1.0) specifies the normalized power rate relative to the
|
|||
|
|
battery's nominal maximum charge power. A value of 1.0 corresponds to full-rate charging, while 0.0
|
|||
|
|
indicates no power transfer. Intermediate values scale the power proportionally.
|
|||
|
|
|
|||
|
|
## Home Appliance
|
|||
|
|
|
|||
|
|
The optimization algorithm supports one start of the home appliance within the optimization
|
|||
|
|
horizon.
|
|||
|
|
|
|||
|
|
### Home Appliance Simulation
|
|||
|
|
|
|||
|
|
### Home Appliance Configuration
|
|||
|
|
|
|||
|
|
Home appliance to run within the optimization horizon.
|
|||
|
|
|
|||
|
|
```json
|
|||
|
|
[
|
|||
|
|
{
|
|||
|
|
"device_id": "dishwasher1",
|
|||
|
|
"consumption_wh": 2000,
|
|||
|
|
"duration_h": 3
|
|||
|
|
}
|
|||
|
|
]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Home appliance to run within a time window of 5 hours starting at 8:00 every day and another time
|
|||
|
|
window of 3 hours starting at 15:00 every day. See
|
|||
|
|
[Time Window Sequence Configuration](configtimewindow-page) for more information.
|
|||
|
|
|
|||
|
|
```json
|
|||
|
|
[
|
|||
|
|
{
|
|||
|
|
"device_id": "dishwasher1",
|
|||
|
|
"consumption_wh": 2000,
|
|||
|
|
"duration_h": 3,
|
|||
|
|
"time_windows": {
|
|||
|
|
"windows": [
|
|||
|
|
{
|
|||
|
|
"start_time": "08:00",
|
|||
|
|
"duration": "5 hours"
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"start_time": "15:00",
|
|||
|
|
"duration": "3 hours"
|
|||
|
|
}
|
|||
|
|
]
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
:::{admonition} Note
|
|||
|
|
:class: note
|
|||
|
|
The optimization algorithm always restricts to one start within the optimization horizon per
|
|||
|
|
energy management run.
|
|||
|
|
:::
|
|||
|
|
|
|||
|
|
### Home Appliance Instructions
|
|||
|
|
|
|||
|
|
The home appliance instructions assume an idealized home appliance model. Under this model,
|
|||
|
|
the home appliance can be operated in two operation modes:
|
|||
|
|
|
|||
|
|
| **Operation Mode ID** | **Description** |
|
|||
|
|
|-----------------------|-------------------------------------------------------------------------|
|
|||
|
|
| **RUN** | The home appliance is started and runs until the end of it's power |
|
|||
|
|
| | sequence. |
|
|||
|
|
| **IDLE** | The home appliance does not run. |
|
|||
|
|
|
|||
|
|
The **operation mode factor** (0.0–1.0) is ignored.
|