Skip to content

Use Cases

This chapter outlines core OSCP 2.0 interaction patterns grouped into connectivity, capacity distribution, metering, and fallback/error handling. Unless stated otherwise, all use cases assume systems are online. Arrow conventions from the specification: thick arrows are OSCP messages; thin arrows are out-of-scope messages.

Sequence Flows

Core Flows

  • Registration & Handshake: exchange endpoints, tokens, preferences, and heartbeat interval.
  • Capacity Forecasts: CP → FP (and FP → CO) send CC/GC/FCC/FGC/Optimum series.
  • Capacity Adjustments: FP → CP requests temporary changes to assigned capacities.
  • Metering: FP → CP aggregated group data; FP → CO asset-level data to improve optimisation.
  • Heartbeats & Offline Handling: Maintain liveness; fall back to FCC/FGC when offline.
sequenceDiagram
    autonumber

    participant CP as Capacity Provider
    participant FP as Flexibility Provider
    participant CO as Capacity Optimiser
    participant FR as Flexibility Resources

    FP->>CP: Register endpoints and exchange tokens
    CP-->>FP: Registration confirmed
    FP->>CP: Handshake (capabilities, heartbeat interval)
    CP-->>FP: HandshakeAcknowledge (offline_mode_at)
    CP-->>FP: Heartbeat to signal liveness
    CP-->>FP: CapacityForecast (CC/GC/FCC/FGC series)
    FP-->>CO: Forward capacity forecast for optimisation
    CO-->>FP: Optimum recommendations
    FP-->>FR: Enforce limits and Optimum targets on devices
    FP->>CP: AdjustGroupCapacityForecast (temporary capacity request)
    FP->>CP: GroupMeasurements (aggregated usage/compliance)
    FP->>CO: AssetMeasurements (per-resource detail)

Connectivity

Flexibility Provider registers its Capacity capabilities

Use case 5: FP registers with CP to establish mutual authentication before any OSCP messages; assumes the parties have never communicated.

Scenario

  • FP generates TOKEN_A and sends it with its base endpoint to CP through a secure, out-of-scope channel.
  • CP generates TOKEN_B (used by FP when calling CP) and sends a Register message listing all OSCP versions and endpoints it supports, authenticating with TOKEN_A.
  • FP chooses an OSCP version, replies HTTP 204, and generates TOKEN_C (used by CP from now on).
  • CP replies HTTP 204.
  • TOKEN_A becomes invalid; TOKEN_C replaces it.
sequenceDiagram
    participant CP as Capacity Provider
    participant FP as Flexibility Provider

    FP->>CP: Send TOKEN_A + FP base endpoint (out-of-band)
    CP->>FP: Register(TOKEN_B, supported OSCP versions)
    FP-->>CP: HTTP 204
    CP->>FP: Authenticate using TOKEN_A
    FP->>CP: Register(TOKEN_C, selected OSCP version)
    CP-->>FP: HTTP 204

Postconditions

  • Success: Registration completed; CP may initiate handshake.
  • Failure:
  • FP does not support any of CP’s OSCP versions → FP returns HTTP 501
  • CP can still authenticate using old token (TOKEN_A) → invalid registration

Capacity Provider handshakes with Flexibility Provider

Use case 6: After registration, CP and FP exchange preferences (e.g., heartbeat interval) via handshake.

Scenario

  • CP sends Handshake to FP.
  • FP returns HTTP 204, then sends HandshakeAcknowledge.
  • CP returns HTTP 204.
sequenceDiagram
    participant CP as Capacity Provider
    participant FP as Flexibility Provider

    CP->>FP: Handshake
    FP-->>CP: HTTP 204
    FP->>CP: HandshakeAcknowledge
    CP-->>FP: HTTP 204

Postconditions

  • Success: Connection established; OSCP messages may now flow.
  • Failure:
  • FP rejects preferences → HTTP 400
  • CP rejects FP’s acknowledgement → HTTP 400

Distribute Capacity

Capacity Provider distributes Capacities to FP(s)

Use case 1: CP delivers CC/GC/FCC/FGC/Optimum values to FP, which applies them to its FRs.

Scenario

  • CP receives grid or metering data (out of scope) and computes the Capacity Forecast (out of scope).
  • CP → FP: UpdateGroupCapacityForecast.
  • FP applies the capacities to its FRs.
  • FRs send metering data to FP.
  • FP → CP: UpdateGroupMeasurements.
sequenceDiagram
    participant CP as Capacity Provider
    participant FP as Flexibility Provider(s)
    participant FR as Flexibility Resource(s)

    loop Every period
        CP->>CP: Compute capacity (non-OSCP)
        CP->>FP: UpdateGroupCapacityForecast
        FP-->>CP: HTTP 204

        opt If needed
            FP->>FR: Adjust capacity
        end
    end

    loop Every period
        loop Every cycle
            FR->>FP: Metering data
        end
        FP->>CP: UpdateGroupMeasurements
        CP-->>FP: HTTP 204
    end

Postconditions

  • Success: CP capacities are accepted and applied to FRs; FP continues to report measurements per schedule.
  • Failure: If forecasts are rejected or cannot be applied, FP should notify CP (compliance error) and operate within safe fallback limits.

Requirements (FR.01.x)

  • FP MUST send aggregated measurements.
  • CP MUST lower capacity to a guaranteed safe value if it loses meter visibility.
  • Fallback capacities MUST be used when offline.
  • Consumption capacity MUST be ≥ 0.
  • Generation capacity MUST be ≤ 0.
  • Fallback values must not exceed their respective normal capacities.
  • Optimum must lie between GC and CC.

Capacity Optimizer distributes Optimum

Use case 2: CO computes and returns Optimum values based on CP’s forecast; FP uses them to steer FRs.

Scenario

  • CP computes a forecast and sends it to FP.
  • FP forwards it to CO.
  • CO computes Optimum and sends it back to FP.
  • FP instructs FRs accordingly.
  • FP sends aggregated meter data to CP and asset-level meter data to CO.
sequenceDiagram
    participant CP as Capacity Provider
    participant FP as Flexibility Provider
    participant CO as Capacity Optimizer
    participant FR as Flexibility Resource(s)

    loop Every period
        CP->>FP: UpdateGroupCapacityForecast
        FP-->>CP: HTTP 204

        FP->>CO: UpdateGroupCapacityForecast
        CO-->>FP: HTTP 204

        CO->>CO: Compute Optimum (forecast, weather, prices, etc.)
        CO->>FP: UpdateGroupCapacityForecast(Optimum)
        FP-->>CO: HTTP 204

        opt If needed
            FP->>FR: Adjust capacity
        end
    end

    loop Every period
        loop Every cycle
            FR->>FP: Metering data
        end
        FP->>CP: UpdateGroupMeasurements
        CP-->>FP: HTTP 204
        FP->>CO: UpdateAssetMeasurements
        CO-->>FP: HTTP 204
    end

Postconditions

  • Success: FP applies CO’s Optimum recommendations and enforces them on FRs while continuing to report measurements to CP/CO.
  • Failure: If Optimum delivery fails, FP should fall back to CP’s forecast and notify CO; degraded optimisation may increase grid load variability.

Flexibility Provider requests additional Capacity

Use case 3: FP asks CP for more capacity when forecasts are insufficient.

Scenario

  • CP sends forecast to FP.
  • FP determines capacity is insufficient.
  • FP → CP: AdjustGroupCapacityForecast.
sequenceDiagram
    participant CP as Capacity Provider
    participant FP as Flexibility Provider

    loop Continuous
        FP->>FP: Determine if additional capacity needed

        opt Extra capacity required
            FP->>CP: AdjustGroupCapacityForecast
            CP-->>FP: HTTP 204

            CP->>FP: UpdateGroupCapacityForecast
            FP-->>CP: HTTP 204
        end
    end

Postconditions

  • Success: Additional capacity is granted and enforced on FRs for the requested period.
  • Failure: Requests may be denied; FP must plan within existing capacities or invoke fallback behaviours to stay compliant.

Distribute Measurements

CO enhances optimization based on EV session data

Use case 4: CO optimizes using EV session details from FP/FR, sending Optimum guidance back during charging sessions.

Scenario

  • Driver plugs in and authorizes; EV begins charging at default limit.
  • FR periodically sends metering data to FP.
  • FP → CO: UpdateAssetMeasurements.
  • CO → FP: UpdateGroupCapacityForecast (Optimum).
  • FP adjusts FR limits if needed.
  • Driver ends session; session stop and meter data are sent.
sequenceDiagram
    participant CO
    participant FP
    participant FR
    participant EV as EV + Driver

    EV->>FR: Plug in
    EV->>FR: Swipe card (authorize)
    FR->>EV: Start charging (default limit)

    loop Session active
        FR->>FP: Metering data
    end

    loop Every period
        FP->>CO: UpdateAssetMeasurements(CHARGING)
        CO-->>FP: HTTP 204

        CO->>FP: UpdateGroupCapacityForecast(Optimum)
        FP-->>CO: HTTP 204

        opt If needed
            FP->>FR: Adjust capacity
            FR->>EV: Adjust charging speed
        end
    end

    EV->>FR: Swipe card (stop)
    FR->>FP: Session stop + meter data
    EV->>FR: Unplug

Postconditions

  • Success: Optimum forecasts are applied to active sessions; CO continues to receive measurements to refine recommendations.
  • Failure: Missing measurements or rejected forecasts halt optimisation; FP should revert to CP-provided capacities and alert operators.

Fallback and Error Situations

FP cannot comply with Capacity Forecast

Use case 7: FP signals non-compliance to CP when events prevent following a capacity forecast.

Scenario

  • CP sends new capacity forecast.
  • FP configures FRs.
  • An event prevents compliance.
  • FP → CP: GroupCapacityComplianceError.
sequenceDiagram
    participant CP
    participant FP
    participant FR

    CP->>FP: UpdateGroupCapacityForecast
    FP-->>CP: HTTP 204

    FP->>FR: Adjust capacity

    FR->>FP: Event (cannot comply)
    FP->>CP: GroupCapacityComplianceError
    CP-->>FP: HTTP 204

Postconditions

  • Success: CP is informed of non-compliance and can adjust capacities or investigate the root cause.
  • Failure: If the error is not delivered, FP should still operate safely within fallback limits and continue retrying with correlation IDs.

Detect an offline situation

Use case 8: Parties detect offline states based on missed heartbeats and timeouts.

sequenceDiagram
    participant A as Party A
    participant B as Party B

    A->>B: Heartbeat(off_mode_at = t1)
    B-->>A: HTTP 204

    A->>B: Heartbeat(off_mode_at = t2)
    B-->>A: HTTP 204

    A->>B: Heartbeat(off_mode_at = t3)
    B-->>A: HTTP 204

    A--X B: Sender offline

    B->>B: Wait until current_time >= t3
    B->>B: Detect offline state

Postconditions

  • Success: Receiver transitions to offline posture after offline_mode_at; sender must re-handshake before resuming normal traffic.
  • Failure: If offline is not detected, parties may overrun safe capacities; tighten heartbeat intervals and monitoring.

FP adapts when CP is offline

Use case 9: FP applies fallback capacities while CP is offline and restores normal operation after a renewed handshake.

Scenario

  • CP becomes unreachable and FP detects offline state.
  • FP uses fallback capacities for FRs.
  • CP returns and initiates handshake; FP responds with HandshakeAcknowledge.
  • FP restores normal capacities.
sequenceDiagram
    participant CP as Capacity Provider
    participant FP as Flexibility Provider
    participant FR as Flexibility Resource

    CP->>FP: UpdateGroupCapacityForecast
    CP--XFP: Offline

    FP->>FP: Detect offline
    FP->>FR: Apply fallback capacities

    CP->>FP: Handshake (restored)
    FP-->>CP: HTTP 204
    FP->>CP: HandshakeAcknowledge
    CP-->>FP: HTTP 204

    FP->>FR: Restore normal capacities

Postconditions

  • Success: FP stays within FCC/FGC while CP is absent and cleanly returns to normal capacities after handshake.
  • Failure: If fallback is not applied, FRs may exceed safe limits; if handshake fails, remain in fallback and alert operations.