Skip to content

Topology & Architecture

Informative overview of the OSCP 2.0 architecture, modernized from OSCP 1.0 by using abstract actors (Capacity Provider, Flexibility Provider, Flexibility Resource, Capacity Optimizer) to cover EV charging, PV, batteries, buildings, and broader flexibility use cases.

Introduction

OSCP 2.0 retains the conceptual model of OSCP 1.0 but drops domain-specific names (e.g., DSO, CSO, EV) so it can be applied across general energy flexibility scenarios.

Domain Model

Flexibility Resources

Flexibility Resources (FRs) are controllable devices that consume or generate energy, such as:

  • EV chargers
  • Stationary batteries
  • Heat pumps
  • PV systems

FRs adjust consumption or generation based on external instructions.

Flexibility Provider

A Flexibility Provider (FP) manages a set of FRs and is responsible for:

  • Controlling charging, discharging, or load adjustments
  • Ensuring FR behavior complies with limits set by a Capacity Provider

Examples include Charging Station Operators (CSOs) and Energy Management Systems (EMS) controlling batteries or building loads.

Capacity Provider

A Capacity Provider (CP) monitors a network segment and imposes consumption or generation limits. CPs do not control individual devices; they communicate aggregate limits to an FP. Examples include:

  • DSO managing a transformer
  • EMS managing a building’s grid connection

Capacity Optimizer

An optional Capacity Optimizer (CO) produces Optimum values to help an FP use available capacity efficiently. Inputs may include:

  • Weather forecasts
  • Energy price projections
  • Historical consumption
  • PV generation predictions

Topology Summaries

Basic model: CP → FP → FR (CP sets boundaries; FP enforces them on its FRs)

flowchart LR
    CP[Capacity Provider] --> FP[Flexibility Provider]
    FP --> FR[Flexibility Resources]

Model with CO: - CP provides capacity forecasts to FP - FP forwards these to CO - CO computes Optimum forecasts and returns them to FP - FP optimizes FR behavior accordingly

flowchart LR
    CP[Capacity Provider] --> FP[Flexibility Provider]
    FP --> FR[Flexibility Resources]
    FP --> CO[Capacity Optimizer]
    CO --> FP

Capacity Forecast

A Capacity Forecast is a time series describing allowable future consumption or generation for a group of FRs. Each interval can include up to five capacity types.

Capacity Types

Type Meaning Sign
CC – Consumption Capacity Maximum energy that can be consumed Positive
GC – Generation Capacity Maximum energy that can be exported (e.g., battery discharge) Negative
FCC – Fallback Consumption Capacity Maximum consumption allowed in offline mode Positive
FGC – Fallback Generation Capacity Maximum generation allowed in offline mode Negative
O – Optimum Preferred consumption or generation level Positive or negative

The Optimum is a single preferred target value, not a min/max band.

Example Intervals

Type T1 T2 T3 T4
CC 32 16 32 16
GC -10 -10 -10 -10
FCC 8 8 8 8
FGC -5 -5 -5 -5
O 24 15 -4 15 
---
config:
  xyChart:
    height: 320
---
xychart-beta
    title "Capacity Forecast Example"
    x-axis ["T1","T2","T3","T4"]
    y-axis "kW" -12 --> 36
    line "CC" [32,16,32,16]
    line "GC" [-10,-10,-10,-10]
    line "FCC" [8,8,8,8]
    line "FGC" [-5,-5,-5,-5]
    line "O" [24,15,-4,15]

Legend: - O (grey): Optimum target - CC (blue): Consumption Capacity - FGC (yellow): Fallback Generation Capacity - FCC (red): Fallback Consumption Capacity - GC (green): Generation Capacity

Interpretation for T1:

  • Preferred target (Optimum) is 24
  • FP may consume up to 32
  • FP may generate up to 10 (-10)

Requesting Capacity Adjustments

An FP may request more or less capacity using AdjustGroupCapacityForecast when it needs capacity different from the assigned values. OSCP notes that DSOs/TSOs cannot provide differentiated capacity per FP unless explicitly allowed, since they must operate non-discriminatorily.

Capacity Optimizer

The CO computes Optimum values for each interval using inputs such as capacity forecasts, weather forecasts, price signals, historical usage, and third-party analytics. A CO can be an external service, part of an FP or CP, or embedded in an EMS.

Metering

An FP may send metering data to a CP (aggregated group data) and to a CO (per-resource detailed data).

Group Measurements

  • Aggregated usage (e.g., kWh) for all FRs in the group
  • Used by CP to check compliance with capacity limits and to determine new forecasts or assess forecasting quality

Asset Measurements

  • Per-resource energy or instantaneous data
  • Sent to CO to enable more accurate optimization (e.g., EV SoC, power levels)

Connection

Describes how OSCP connections are established and maintained.

Registration

  • Each party generates a unique token
  • Tokens are exchanged through secure out-of-band means
  • Tokens are required for every endpoint
  • Registration must be completed before handshaking

Handshaking

  • The initiating party sends a Handshake message
  • The responding party returns a HandshakeAcknowledge
  • Only after a successful handshake may other OSCP messages be exchanged
  • Used at startup and when recovering from offline states
  • Heartbeat intervals are negotiated as part of the handshake

Offline Detection

Offline state can be inferred from missing heartbeat messages, missing capacity forecasts, or missing metering values. Higher heartbeat frequency enables faster offline detection.

Heartbeats

  • Heartbeats include a timestamp offline_mode_at
  • If no heartbeat is received before that time, the receiver declares the sender Offline
  • Heartbeats must be more frequent than any other OSCP message type

Network Directionality, Trust, and Dependencies

  • Directionality: CP initiates HTTPS to FP for registration, handshake, heartbeats, and capacity forecasts; FP initiates to CP for adjustments and measurements; FP initiates to CO for forecasts and measurements.
  • Trust boundaries: TLS terminates at each party’s base URL; tokens exchanged during registration scope access to those URLs. No intermediate brokers are assumed unless added by the integrator.
  • Dependencies: Optional CO increases optimisation fidelity; FP may depend on FR controllers or CSMS to enforce capacities downstream.