OCPP 2.1 Edition 2 Section K (Part II)

Smart Charging Part II - CSMS Developer Guide

Based on OCPP 2.1 Edition 2 Specification (Part 2), Sections 5.2-5.3. This guide covers external charging limit flows (K11-K14, K23-K27) and ISO 15118 smart charging flows (K15-K20) from the CSMS perspective.

18 Sections

16 Use Cases

K11 – K27

1. Overview

Introduction

This document covers the second half of OCPP 2.1 Smart Charging use cases (K11 through K20, plus K23 through K27). These use cases address scenarios where external systems influence charging behavior and where ISO 15118 communication between EV and Charging Station drives smart charging decisions. The CSMS role ranges from passive acknowledgment to active schedule computation depending on the use case.

Section 5.2: External Charging Limit Based Smart Charging (K11-K14, K23-K27)

In these use cases, an External Control System such as a Distribution System Operator (DSO), smart meter, or Energy Management System (EMS) communicates charging limits to the Charging Station via a non-OCPP protocol. The Charging Station then informs the CSMS about these externally imposed limits using NotifyChargingLimitRequest and ClearedChargingLimitRequest. The CSMS does not set these limits itself but must account for them when computing its own charging profiles.

Section 5.3: ISO 15118 Based Smart Charging (K15-K20)

These use cases cover the interaction between the CSMS and Charging Station when the EV communicates its charging needs via ISO 15118-2 or ISO 15118-20. The Charging Station forwards the EV's charging requirements to the CSMS using NotifyEVChargingNeedsRequest, and the CSMS responds with an optimized charging profile. This includes scheduled and dynamic control modes, renegotiation flows, and schedule adjustment scenarios.

CSMS Role Summary

Message Direction	Message	CSMS Role
CS -> CSMS	`NotifyChargingLimitRequest`	Receive & acknowledge
CS -> CSMS	`ClearedChargingLimitRequest`	Receive & acknowledge
CS -> CSMS	`NotifyEVChargingNeedsRequest`	Receive, process & respond with status
CS -> CSMS	`NotifyEVChargingScheduleRequest`	Receive, validate & respond
CS -> CSMS	`TransactionEventRequest`	Receive & process
CSMS -> CS	`SetChargingProfileRequest`	Initiate & send
CSMS -> CS	`ClearChargingProfileRequest`	Initiate & send

2. K11 — Set/Update External Charging Limit (Ongoing Transaction)

CS-Initiated

Use Case ID	K11
Direction	CS → CSMS
Trigger	External system sets grid limit on CS during active transaction
OCPP Messages	NotifyChargingLimitRequest / NotifyChargingLimitResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)

External Control
System               Charging Station                  CSMS
  |                        |                              |
  |  Set charging limit    |                              |
  |  (non-OCPP protocol)   |                              |
  |---------------------->|                              |
  |                        |                              |
  |                        | NotifyChargingLimitReq(      |
  |                        |   chargingLimit,              |
  |                        |   [chargingSchedule],         |
  |                        |   [evseId])                   |
  |                        |----------------------------->|
  |                        |                              |
  |                        | NotifyChargingLimitRes()     |
  |                        |<-----------------------------|
  |                        |                              |
  |                        | TransactionEventReq(         |
  |                        |   trigger=                    |
  |                        |   ChargingRateChanged)        |
  |                        |----------------------------->|
  |                        |                              |
  |                        | TransactionEventRes()        |
  |                        |<-----------------------------|

Request Payload: NotifyChargingLimitRequest

The Charging Station sends this message to inform the CSMS about externally imposed charging limits during an active transaction.

NotifyChargingLimitRequest — Example

{
  "chargingLimit": {
    "chargingLimitSource": "EMS",
    "isLocalGeneration": false,
    "isGridCritical": true
  },
  "evseId": 1,
  "chargingSchedule": [
    {
      "id": 1,
      "chargingRateUnit": "W",
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 7400 },
        { "startPeriod": 3600, "limit": 11000 }
      ],
      "startSchedule": "2025-03-15T14:00:00Z",
      "duration": 7200
    }
  ]
}

Response: Empty response (only optional customData). The CSMS simply acknowledges receipt.

NotifyChargingLimitResponse

{}

CSMS Processing Logic

Acknowledge immediately — return an empty NotifyChargingLimitResponse.
Record the external limit — store the chargingLimitSource, evseId, and associated chargingSchedule for use in future profile calculations.
Note: chargingLimitSource SHALL NOT be CSO in K11 (K11.FR.05). If received with source CSO, treat it as an error.
Track charging schedules if the configuration variable EnableNotifyChargingLimitWithSchedules is true — the CS will include chargingSchedule data in the request.
Expect a TransactionEventRequest if the charging rate changed significantly (trigger = ChargingRateChanged).
Profile ID considerations — when MaxExternalConstraintsId is configured, externally set profiles use IDs at or below that value. CSMS-set profiles should use IDs above it.

Requirements

Req ID	CSMS Action
`K11.FR.02`	CSMS SHALL respond with NotifyChargingLimitResponse upon receiving NotifyChargingLimitRequest
`K11.FR.03`	CSMS SHALL store the external charging limit information for the station/EVSE
`K11.FR.04`	CSMS SHALL account for external limits when computing its own charging profiles
`K11.FR.05`	chargingLimitSource SHALL NOT be CSO — the CSO sets limits via SetChargingProfileRequest, not externally
`K11.FR.06`	CSMS SHALL expect TransactionEventRequest with trigger ChargingRateChanged when the actual charging rate changes significantly
`K11.FR.07`	CSMS SHALL use profile IDs above MaxExternalConstraintsId (if configured) when sending SetChargingProfileRequest

3. K12 — Set/Update External Charging Limit (No Transaction)

CS-Initiated

Use Case ID	K12
Direction	CS → CSMS
Trigger	External system sets limit on CS without active transaction
OCPP Messages	NotifyChargingLimitRequest / NotifyChargingLimitResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)

External Control
System               Charging Station                  CSMS
  |                        |                              |
  |  Set charging limit    |                              |
  |  (non-OCPP protocol)   |                              |
  |----------------------> |                              |
  |                        |                              |
  |                        | NotifyChargingLimitReq(      |
  |                        |   chargingLimit,             |
  |                        |   [chargingSchedule],        |
  |                        |   [evseId])                  |
  |                        |----------------------------->|
  |                        |                              |
  |                        | NotifyChargingLimitRes()     |
  |                        |<-----------------------------|
  |                        |                              |
  |                        |   [No TransactionEventReq    |
  |                        |    — no active transaction]  |

Implementation Notes

K12 is functionally identical to K11 from the CSMS perspective, with the following key differences:

No TransactionEventRequest expected — since there is no active transaction on the station, the CS will not send a TransactionEventRequest with trigger ChargingRateChanged.
Limit applies to new/future transactions — the externally imposed limit will affect any transactions that start after the limit is set. The CSMS should factor this limit into any charging profiles it sends for future sessions.

Implementation: The CSMS should handle NotifyChargingLimitRequest identically whether or not a transaction is active. Store the external limit and account for it when computing future charging profiles. The only behavioral difference is whether a TransactionEventRequest follows.

Requirements

Req ID	CSMS Action
`K12.FR.01`	The total load on the grid connection point SHALL NOT exceed the limit set by the external system
`K12.FR.02`	CSMS SHALL respond with NotifyChargingLimitResponse upon receiving NotifyChargingLimitRequest
`K12.FR.03`	CSMS SHALL store the external charging limit for the station/EVSE
`K12.FR.04`	CSMS SHALL apply stored external limits when computing charging profiles for new transactions
`K12.FR.05`	CSMS SHALL handle the request identically to K11, except no TransactionEventRequest is expected

4. K13 — Reset/Release External Charging Limit

CS-Initiated

Use Case ID	K13
Direction	CS → CSMS
Trigger	External system releases charging limit
OCPP Messages	ClearedChargingLimitRequest / ClearedChargingLimitResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)

External Control
System               Charging Station                  CSMS
  |                        |                              |
  |  Release limit         |                              |
  |  (non-OCPP protocol)   |                              |
  |----------------------> |                              |
  |                        |                              |
  |                        | ClearedChargingLimitReq(     |
  |                        |   chargingLimitSource,       |
  |                        |   [evseId])                  |
  |                        |----------------------------->|
  |                        |                              |
  |                        | ClearedChargingLimitRes()    |
  |                        |<-----------------------------|
  |                        |                              |
  |                        | [If transaction ongoing:]    |
  |                        | TransactionEventReq(         |
  |                        |   trigger=                   |
  |                        |   ChargingRateChanged)       |
  |                        |----------------------------->|
  |                        |                              |
  |                        | TransactionEventRes()        |
  |                        |<-----------------------------|

Request Payload: ClearedChargingLimitRequest

The Charging Station sends this message when an external system releases a previously imposed charging limit.

ClearedChargingLimitRequest — Example

{
  "chargingLimitSource": "EMS",
  "evseId": 1
}

chargingLimitSource Known Values

EMS — Energy Management System
Other — Other external source
SO — System Operator (DSO/TSO)
CSO — Charging Station Operator

Response: Empty response (only optional customData). The CSMS simply acknowledges receipt.

ClearedChargingLimitResponse

{}

CSMS Processing Logic

Acknowledge immediately — return an empty ClearedChargingLimitResponse.
Clear stored external limit — remove or invalidate the previously stored external limit for the specified chargingLimitSource and evseId (or entire station if evseId is absent).
If a transaction is ongoing, expect a TransactionEventRequest with trigger ChargingRateChanged as the Charging Station adjusts to the released limit.

Requirements

Req ID	CSMS Action
`K13.FR.01`	CSMS SHALL respond with ClearedChargingLimitResponse upon receiving ClearedChargingLimitRequest
`K13.FR.02`	CSMS SHALL remove the stored external limit for the specified chargingLimitSource and evseId
`K13.FR.03`	CSMS SHALL optionally send updated charging profiles to the station now that the external constraint is removed

5. K14 — External Charging Limit with Local Controller

CS-Initiated

Use Case ID	K14
Direction	CS → CSMS (via Local Controller)
Trigger	External system sets limit via Local Controller
OCPP Messages	NotifyChargingLimitRequest / ClearedChargingLimitRequest

Prerequisites: ExternalControlSignalsEnabled = true on the Charging Stations managed by the Local Controller, and there are ongoing transactions on the stations.

Sequence Diagram

Sequence Diagram (CSMS perspective)

External              Local                Charging
System               Controller            Station               CSMS
  |                      |                      |                    |
  |  Set limit           |                      |                    |
  |  (non-OCPP)          |                      |                    |
  |--------------------> |                      |                    |
  |                      |                      |                    |
  |                      | SetChargingProfileReq|                    |
  |                      | (to each CS)         |                    |
  |                      |--------------------> |                    |
  |                      |                      |                    |
  |                      | NotifyChargingLimitReq                    |
  |                      |  (to CSMS, as Local Controller)           |
  |                      |-----------------------------------------> |
  |                      |                      |                    |
  |                      | NotifyChargingLimitRes                    |
  |                      | <-----------------------------------------|
  |                      |                      |                    |
  |   ...later...        |                      |                    |
  |                      |                      |                    |
  |  Release limit       |                      |                    |
  |--------------------> |                      |                    |
  |                      |                      |                    |
  |                      | ClearedChargingLimitReq                   |
  |                      |  (to CSMS)                                |
  |                      |-----------------------------------------> |
  |                      |                      |                    |
  |                      | ClearedChargingLimitRes                   |
  |                      | <-----------------------------------------|

CSMS Implementation

In K14, the CSMS takes a passive role. The Local Controller handles the distribution of charging limits to individual Charging Stations.

Receives NotifyChargingLimitRequest from the Local Controller (not from individual Charging Stations). The Local Controller reports the overall external limit it received.
Receives ClearedChargingLimitRequest from the Local Controller when the external limit is released.
Does NOT need to send SetChargingProfileRequest to individual Charging Stations — the Local Controller handles distribution of limits across its managed stations.

Key Distinction: Unlike K11/K12 where external limits are reported by the Charging Station itself, in K14 the Local Controller acts as the intermediary. The CSMS receives the notification from the Local Controller and stores the information, but the Local Controller is responsible for setting appropriate charging profiles on each station via SetChargingProfileRequest.

Requirements

Req ID	CSMS Action
`K14.FR.01`	CSMS SHALL respond with NotifyChargingLimitResponse upon receiving NotifyChargingLimitRequest from the Local Controller
`K14.FR.02`	CSMS SHALL store the external charging limit reported by the Local Controller
`K14.FR.03`	CSMS SHALL respond with ClearedChargingLimitResponse when the Local Controller reports the limit is cleared
`K14.FR.05`	CSMS SHALL NOT send SetChargingProfileRequest to Charging Stations managed by the Local Controller in response to external limits — the Local Controller handles distribution
`K14.FR.06`	CSMS SHALL account for the reported external limit when performing any higher-level scheduling or optimization across multiple sites

6. K23 — Smart Charging with EMS Connected to Charging Stations

CS-Initiated

Use Case ID	K23
Direction	CS → CSMS
Trigger	EMS sets limits directly on Charging Stations
OCPP Messages	NotifyChargingLimitRequest / NotifyChargingLimitResponse

Architecture

EMS Connected Directly to Charging Stations

                Site
┌──────────────────────────────────────┐
│  DSO ─── Grid ─── Local Gen          │
│              │                       │
│            EMS ── Other Loads        │
│            / \                       │
│   Charging    Charging               │
│   Station 1   Station 2              │
└──────────────────────────────────────┘
          │               │
   NotifyChargingLimit    NotifyChargingLimit
          │               │
          └──────┬────────┘
                CSMS

In this topology the EMS communicates directly with each Charging Station using a non-OCPP protocol. Each CS then independently notifies the CSMS about the limits imposed by the EMS.

CSMS Implementation

The CSMS role is identical to K11/K12 — the only difference is the origin of the external limit (EMS rather than DSO/grid operator). The CSMS receives the notification from each individual Charging Station, not from the EMS itself.

Receive NotifyChargingLimitRequest from each CS (not from EMS) with chargingLimitSource = "EMS".
Respond with an empty NotifyChargingLimitResponse.
If transaction ongoing, expect TransactionEventRequest with trigger = ChargingRateChanged from each affected CS.

Note: The detailed requirements for handling NotifyChargingLimitRequest and ClearedChargingLimitRequest are covered in K11 and K12. The CSMS implementation is the same regardless of whether the external source is a DSO, grid operator, or EMS.

7. K24 — Smart Charging with EMS via Local Controller

CS-Initiated

Use Case ID	K24
Direction	CS → CSMS (via Local Controller)
Trigger	EMS connected to Local Controller that manages CSs
OCPP Messages	NotifyChargingLimitRequest / NotifyChargingLimitResponse

Architecture

EMS Connected to Local Controller

                Site
┌───────────────────────────────────────────┐
│  Local PV Gen    Other Loads      CSMS    │
│       │              │          (optional │
│       └──────────────┘          TxProfile)│
│              │                     │      │
│   EMS ── Local Controller ─────────┘      │
│              / \                          │
│  MaxProfile 1   MaxProfile 2              │
│       │              │                    │
│   CS 1          CS 2                      │
└───────────────────────────────────────────┘

In this topology the EMS communicates with a Local Controller, which in turn manages the Charging Stations using SetChargingProfileRequest with purpose ChargingStationMaxProfile. The Local Controller aggregates the CSMS notifications to a single NotifyChargingLimitRequest toward the CSMS.

CSMS Implementation

Receive NotifyChargingLimitRequest from the Local Controller (NOT from individual CSs) with chargingLimitSource = "EMS".
Expect TransactionEventRequest from individual CSs with trigger = ChargingRateChanged when the Local Controller adjusts their charging profiles.
Local Controller sends SetChargingProfileRequest with purpose ChargingStationMaxProfile to CSs — the CSMS is not involved in this step.

Warning: The chargingProfilePurpose used by the Local Controller must NOT be ChargingStationExternalConstraints because the Local Controller is not an External Control System. It must use ChargingStationMaxProfile instead.

Note: The detailed requirements for handling external limits via a Local Controller are covered in K14. The CSMS receives notifications from the Local Controller and transaction events from individual CSs using the same message flow.

8. K25 — Smart Charging with EMS as Local Controller

CS-Initiated

Use Case ID	K25
Direction	CS → CSMS
Trigger	Combined EMS/Local Controller manages CSs
OCPP Messages	NotifyChargingLimitRequest / NotifyChargingLimitResponse

This use case is identical to K24. In K25 the EMS and Local Controller are combined into a single device rather than being separate components. From the CSMS perspective there is no difference — it receives NotifyChargingLimitRequest from the combined EMS/Local Controller and TransactionEventRequest from individual CSs.

The combined device acts as a Local Controller toward both the CSMS and the Charging Stations. It sends SetChargingProfileRequest with purpose ChargingStationMaxProfile to the CSs and NotifyChargingLimitRequest with chargingLimitSource = "EMS" to the CSMS.

Note: The detailed requirements for this topology are covered in K14. The CSMS implementation is identical to K24 — process NotifyChargingLimitRequest from the combined EMS/Local Controller and track TransactionEventRequest messages from individual CSs.

9. K26 — Smart Charging with Hybrid Local & Cloud EMS

CS-Initiated

Use Case ID	K26
Direction	CS → CSMS
Trigger	Hybrid cloud/local EMS architecture
OCPP Messages	NotifyChargingLimitRequest / NotifyChargingLimitResponse

Topologies

Topology 1: Cloud EMS as Local Controller

The Cloud EMS acts as Local Controller connected to both the CSMS and the Charging Stations. It receives scheduling information from the cloud and communicates limits to each CS using SetChargingProfileRequest with purpose ChargingStationMaxProfile. A Local EMS on-site measures loads and acts as a fail-safe in case the cloud connection is lost.

Topology 2: Local EMS as Local Controller

The Local EMS acts as the Local Controller and directly manages the Charging Stations. The Cloud EMS handles scheduling and optimization only, providing guidance to the Local EMS. The Local EMS is responsible for real-time load balancing and communicating with the CSs and CSMS.

CSMS Implementation

In both topologies the CSMS behavior is identical to K24/K25:

Receive NotifyChargingLimitRequest from whichever component acts as the Local Controller (Cloud EMS or Local EMS) with chargingLimitSource = "EMS".
Receive TransactionEventRequest from individual CSs with trigger = ChargingRateChanged when charging profiles are adjusted.
Respond with an empty NotifyChargingLimitResponse to acknowledge receipt.

Note: The detailed requirements for handling external limits via a Local Controller are covered in K14. Regardless of whether the Local Controller role is fulfilled by a Cloud EMS, Local EMS, or a hybrid combination, the CSMS processes the same OCPP messages in the same way.

10. K27 — Smart Charging with EMS and LocalGeneration

CS-Initiated

Use Case ID	K27
Direction	CS → CSMS
Trigger	Local power generation (e.g. PV panels) adds extra capacity
OCPP Messages	NotifyChargingLimitRequest / NotifyChargingLimitResponse

Concept

When a Charging Station has access to local generation (e.g. PV panels), this extra capacity can be added on top of the normal TxDefaultProfile limit. The station represents this as chargingProfilePurpose = LocalGeneration. Unlike external constraints which impose upper limits, LocalGeneration profiles represent additional available capacity that increases the effective charging limit.

Example: LocalGeneration Adding to TxDefaultProfile

CSMS sets: TxDefaultProfile, Relative, limit = 5000W

EMS provides: LocalGeneration schedule [t=0: 2kW] [t=3600: 1kW]

Result:

First period (0–3600s): 5000 + 2000 = 7000W
Second period (3600s+): 5000 + 1000 = 6000W

Sequence Diagram

Sequence Diagram (CSMS perspective)

EMS              Charging Station                          CSMS
 |                    |                                     |
 |                    |  SetChargingProfileReq(             |
 |                    |    TxDefaultProfile, limit=5kW)     |
 |                    |<------------------------------------|
 |                    |                                     |
 |                    |  SetChargingProfileResp(Accepted)   |
 |                    |------------------------------------>|
 |                    |                                     |
 | LocalGen schedule  |                                     |
 | (2kW, then 1kW)    |                                     |
 |------------------->|                                     |
 |                    |                                     |
 |                    | NotifyChargingLimitReq(             |
 |                    |   chargingLimit: {                  |
 |                    |     chargingLimitSource: "EMS",     |
 |                    |     isLocalGeneration: true },      |
 |                    |   chargingSchedule: [...])          |
 |                    |------------------------------------>|
 |                    |                                     |
 |                    | NotifyChargingLimitResp()           |
 |                    |<------------------------------------|

CSMS Implementation: Handling LocalGeneration Notifications

Acknowledge with an empty NotifyChargingLimitResponse.
Understand that this represents extra available capacity, not a limitation. When isLocalGeneration = true, the reported schedule is additive power that the station can use on top of its normal profiles.
Store the local generation schedule for the station/EVSE. Use this information when computing composite schedules or making smart charging decisions.
Track chargingSchedule entries representing LocalGeneration profiles. These schedules indicate the time-varying power output from local generation sources (e.g. solar panels with varying output throughout the day).
Note: The station sends schedules for both LocalGeneration and ChargingStationExternalConstraints together in the same NotifyChargingLimitRequest (K27.FR.05). The CSMS must distinguish between them using the isLocalGeneration flag.

Requirements

Requirement	Description
`K27.FR.01`	When the Charging Station has access to local generation, the EMS SHALL provide the local generation schedule to the Charging Station.
`K27.FR.02`	The Charging Station SHALL send a NotifyChargingLimitRequest to the CSMS with isLocalGeneration = true and the local generation charging schedule.
`K27.FR.03`	The local generation power SHALL be added on top of the applicable TxDefaultProfile limit to compute the effective charging limit.
`K27.FR.04`	The CSMS SHALL acknowledge with an empty NotifyChargingLimitResponse.
`K27.FR.05`	The Charging Station SHALL include both LocalGeneration and ChargingStationExternalConstraints schedules in the same NotifyChargingLimitRequest when both are present.

11. K15 — ISO 15118-2 Charging with Load Leveling

ISO 15118

Use Case ID	K15
Direction	Bidirectional
Trigger	EV sends ChargeParameterDiscoveryReq via ISO 15118
OCPP Messages	NotifyEVChargingNeedsReq/Res + SetChargingProfileReq/Res + NotifyEVChargingScheduleReq/Res

Prerequisites

Both Charging Station and EV support ISO 15118
Transaction has already been started before ChargeParameterDiscoveryReq is received
TxStartPoint contains at least one of: ParkingBayOccupied, EVConnected, Authorized, PowerPathClosed

Sequence Diagram

K15 — ISO 15118-2 Charging with Load Leveling

EV              Charging Station                              CSMS
 |                      |                                       |
 |                      |--- TransactionEventReq (Started) ---->|
 |                      |<-- TransactionEventRes ---------------|
 |                      |                                       |
 |--ChargeParamDiscReq->|                                       |
 |                      |--- NotifyEVChargingNeedsReq --------->|
 |                      |<-- NotifyEVChargingNeedsRes ----------|
 |                      |    (status=Accepted/Processing/       |
 |                      |     Rejected)                         |
 |                      |                                       |
 |                      |<-- SetChargingProfileReq -------------|
 |                      |--- SetChargingProfileRes ------------>|
 |                      |                                       |
 |<--ChargeParamDiscRes-|                                       |
 |   (SAScheduleList)   |                                       |
 |                      |                                       |
 |--PowerDeliveryReq--->|                                       |
 |<--PowerDeliveryRes---|                                       |
 |                      |                                       |
 |                      |  [opt: if EV provides charging schedule]
 |                      |--- NotifyEVChargingScheduleReq ------>|
 |                      |<-- NotifyEVChargingScheduleRes -------|

Handling NotifyEVChargingNeedsRequest

When the EV sends a ChargeParameterDiscoveryReq via ISO 15118, the Charging Station forwards the EV's charging requirements to the CSMS.

NotifyEVChargingNeedsRequest — Example

{
  "evseId": 1,
  "chargingNeeds": {
    "requestedEnergyTransfer": "DC",
    "departureTime": "2025-03-15T18:00:00Z",
    "controlMode": "ScheduledControl",
    "mobilityNeedsMode": "EVCC_SECC",
    "acChargingParameters": {
      "energyAmount": 30000,
      "evMinCurrent": 6,
      "evMaxCurrent": 32,
      "evMaxVoltage": 230
    },
    "dcChargingParameters": {
      "evMaxCurrent": 200,
      "evMaxVoltage": 500,
      "evMaxPower": 100000,
      "evEnergyCapacity": 75000,
      "energyAmount": 50000,
      "stateOfCharge": 30,
      "fullSoC": 100,
      "bulkSoC": 80
    },
    "v2xChargingParameters": {
      "maxChargePower": 11000,
      "minChargePower": 1380,
      "maxDischargePower": 11000,
      "minDischargePower": 1380,
      "maxChargeCurrent": 48,
      "minChargeCurrent": 6,
      "maxDischargeCurrent": 48,
      "minDischargeCurrent": 6,
      "minVoltage": 200,
      "maxVoltage": 500,
      "evTargetEnergyRequest": 50000,
      "evMinEnergyRequest": 20000,
      "evMaxEnergyRequest": 75000,
      "evMinV2XEnergyRequest": 10000,
      "evMaxV2XEnergyRequest": 40000,
      "targetSoC": 80
    },
    "evEnergyOffer": {
      "evEnergyOfferList": [
        {
          "evPowerSchedule": {
            "duration": 3600,
            "evPowerScheduleEntries": [
              { "startPeriod": 0, "power": -5000 },
              { "startPeriod": 1800, "power": -3000 }
            ]
          },
          "evAbsolutePriceSchedule": null
        }
      ]
    }
  },
  "maxScheduleTuples": 12,
  "timestamp": "2025-03-15T14:00:00Z"
}

NotifyEVChargingNeedsResponse — Example

{
  "status": "Accepted",
  "statusInfo": {
    "reasonCode": "ScheduleReady",
    "additionalInfo": "Charging profile will be sent within 60 seconds"
  }
}

Response Status Values

Status	Meaning	CSMS Action
`Accepted`	CSMS will provide a schedule	Follow up with SetChargingProfileRequest within 60 seconds
`Rejected`	CSMS will NOT provide a schedule	Station uses TxDefaultProfile or allows unlimited power
`Processing`	CSMS needs more time to compute	Follow up later with SetChargingProfileRequest (triggers K16 renegotiation)
`NoChargingProfile`	CSMS will not provide a profile (K18/K19 only)	Station uses TxDefaultProfile or max EVSE power

CSMS Processing Logic

Receive and validate the EV charging needs — check requestedEnergyTransfer, departureTime, and charging parameters for consistency.
Evaluate whether the requested needs can be met given current grid constraints, energy pricing, and station capacity.
Compute an optimal charging schedule that respects maxScheduleTuples and the EV's min/max power boundaries.
Respond with the appropriate status — Accepted if a profile will be sent, Processing if more time is needed, or Rejected if the needs cannot be met.
Send a SetChargingProfileRequest with purpose TxProfile within 60 seconds if status was Accepted.

Sending SetChargingProfileRequest

After accepting the EV's charging needs, the CSMS sends a charging profile to the station. The profile is converted into an ISO 15118 SAScheduleList for the EV.

SetChargingProfileRequest — Example

{
  "evseId": 1,
  "chargingProfile": {
    "id": 100,
    "stackLevel": 1,
    "chargingProfilePurpose": "TxProfile",
    "chargingProfileKind": "Absolute",
    "transactionId": "tx-abc-12345",
    "chargingSchedule": [
      {
        "id": 1,
        "chargingRateUnit": "W",
        "chargingSchedulePeriod": [
          { "startPeriod": 0, "limit": 7400 },
          { "startPeriod": 3600, "limit": 11000 },
          { "startPeriod": 7200, "limit": 22000 }
        ],
        "startSchedule": "2025-03-15T14:00:00Z",
        "duration": 14400,
        "salesTariff": {
          "id": 1,
          "salesTariffEntry": [
            {
              "relativeTimeInterval": {
                "start": 0,
                "duration": 3600
              },
              "ePriceLevel": 2
            },
            {
              "relativeTimeInterval": {
                "start": 3600,
                "duration": 3600
              },
              "ePriceLevel": 1
            },
            {
              "relativeTimeInterval": {
                "start": 7200,
                "duration": 7200
              },
              "ePriceLevel": 0
            }
          ]
        }
      }
    ],
    "validFrom": "2025-03-15T14:00:00Z",
    "validTo": "2025-03-15T18:00:00Z"
  }
}

Key Rules

Req ID	Rule
`K15.FR.07`	CSMS SHALL send SetChargingProfileRequest with chargingProfilePurpose = TxProfile
`K15.FR.08`	The charging profile SHALL contain a chargingSchedule that respects the EV's min/max power boundaries
`K15.FR.18`	CSMS SHALL send the SetChargingProfileRequest within 60 seconds of responding Accepted to NotifyEVChargingNeedsRequest
`Period limit`	The number of chargingSchedulePeriod entries SHALL NOT exceed maxScheduleTuples reported by the station

Handling NotifyEVChargingScheduleRequest

After the EV receives the SAScheduleList and selects a schedule, the Charging Station optionally reports the EV's chosen charging schedule back to the CSMS.

NotifyEVChargingScheduleRequest — Example

{
  "timeBase": "2025-03-15T14:00:00Z",
  "evseId": 1,
  "chargingSchedule": {
    "id": 1,
    "chargingRateUnit": "W",
    "chargingSchedulePeriod": [
      { "startPeriod": 0, "limit": 7400 },
      { "startPeriod": 3600, "limit": 11000 }
    ],
    "duration": 7200
  },
  "selectedChargingScheduleId": 1,
  "powerToleranceAcceptance": true
}

NotifyEVChargingScheduleResponse — Example

{
  "status": "Accepted",
  "statusInfo": {
    "reasonCode": "WithinLimits",
    "additionalInfo": "EV schedule is within the allowed charging boundaries"
  }
}

Processing Logic

Validate the EV's chosen schedule against the boundaries defined in the charging profile that was sent.
If within limits — respond with Accepted (K15.FR.11). The EV's schedule is acceptable and charging proceeds.
If NOT within limits — respond with Rejected (K15.FR.12). The EV's schedule exceeds the allowed boundaries.
If Rejected — start a K16 renegotiation by sending a new SetChargingProfileRequest with updated limits (K15.FR.13).

12. K16 — Renegotiation Initiated by CSMS

CSMS-Initiated

Use Case ID	K16
Direction	CSMS → CS
Trigger	CSMS decides new schedule mid-session
OCPP Messages	SetChargingProfileReq/Res + NotifyEVChargingScheduleReq/Res

Sequence Diagram

K16 — CSMS-Initiated Renegotiation

EV              Charging Station                              CSMS
 |                      |                                       |
 |  [Charging in progress...]                                   |
 |                      |                                       |
 |                      |       [CSMS decides new schedule]     |
 |                      |                                       |
 |                      |<-- SetChargingProfileReq -------------|
 |                      |--- SetChargingProfileRes ------------>|
 |                      |    (status=Accepted)                  |
 |                      |                                       |
 |  [Station triggers ISO 15118 renegotiation with EV]          |
 |                      |                                       |
 |                      |  [opt: if EV provides charging schedule]
 |                      |--- NotifyEVChargingScheduleReq ------>|
 |                      |<-- NotifyEVChargingScheduleRes -------|

Implementation

The CSMS initiates this flow when it needs to update the charging schedule during an active ISO 15118 session. This can be triggered by updated grid conditions, pricing changes, demand response events, or other operational needs.

Build a new charging profile based on updated grid conditions, pricing, demand response, or other operational requirements.
Send SetChargingProfileRequest with chargingProfilePurpose = TxProfile to the Charging Station.
Handle SetChargingProfileResponse — expect status = Accepted (K16.FR.01). The station will trigger an ISO 15118 renegotiation with the EV.
Handle NotifyEVChargingScheduleRequest if the EV returns a charging schedule:
- Validate the EV's schedule against the profile boundaries
- Respond Accepted if within limits (K16.FR.06)
- Respond Rejected if the schedule exceeds allowed boundaries (K16.FR.07)
- If Rejected, start a new renegotiation by sending another SetChargingProfileRequest (K16.FR.08)
If the station sends a NotifyEVChargingNeedsRequest during renegotiation (K16.FR.09 says the station SHOULD NOT do this), the CSMS SHALL send a new SetChargingProfileRequest in response (K16.FR.12).

Warning: Per K16.FR.09, the Charging Station SHOULD NOT send a NotifyEVChargingNeedsRequest during a CSMS-initiated renegotiation. However, the CSMS must still be prepared to handle it gracefully if received.

Requirements

Req ID	CSMS Action
`K16.FR.01`	CSMS SHALL send SetChargingProfileRequest with TxProfile purpose to initiate renegotiation
`K16.FR.06`	CSMS SHALL respond Accepted to NotifyEVChargingScheduleRequest when the EV schedule is within allowed boundaries
`K16.FR.07`	CSMS SHALL respond Rejected to NotifyEVChargingScheduleRequest when the EV schedule exceeds allowed boundaries
`K16.FR.08`	CSMS SHALL initiate a new renegotiation (send new SetChargingProfileRequest) when it rejects the EV schedule
`K16.FR.09`	Charging Station SHOULD NOT send NotifyEVChargingNeedsRequest during a CSMS-initiated renegotiation
`K16.FR.11`	CSMS SHALL account for current EV charging needs when building the new profile
`K16.FR.12`	If NotifyEVChargingNeedsRequest is received during renegotiation, CSMS SHALL respond and send a new SetChargingProfileRequest

13. K17 — Renegotiation Initiated by EV

CS-Initiated

Use Case ID	K17
Direction	CS → CSMS
Trigger	EV requests new charging schedule mid-session
OCPP Messages	NotifyEVChargingNeedsReq/Res + SetChargingProfileReq/Res + NotifyEVChargingScheduleReq/Res

Sequence Diagram

K17 — EV-Initiated Renegotiation

EV              Charging Station                              CSMS
 |                      |                                       |
 |  [Charging in progress...]                                   |
 |                      |                                       |
 |  [EV triggers renegotiation]                                 |
 |                      |--- NotifyEVChargingNeedsReq --------->|
 |                      |<-- NotifyEVChargingNeedsRes ----------|
 |                      |    (status=Accepted)                  |
 |                      |                                       |
 |                      |<-- SetChargingProfileReq -------------|
 |                      |--- SetChargingProfileRes ------------>|
 |                      |    (Accepted)                         |
 |                      |                                       |
 |                      |  [opt: if EV provides charging schedule]
 |                      |--- NotifyEVChargingScheduleReq ------>|
 |                      |<-- NotifyEVChargingScheduleRes -------|

Implementation

This flow is almost identical to K15 but occurs mid-session. The EV requests updated charging parameters (e.g., changed departure time, different energy needs), and the Charging Station forwards the new requirements to the CSMS.

Receive NotifyEVChargingNeedsRequest with the EV's updated charging parameters (new departure time, energy requirements, SoC targets, etc.).
Respond with status:
- Accepted — CSMS will compute and send a new profile
- Rejected — CSMS cannot meet the updated needs
- Processing — CSMS needs more time to compute
Calculate a new charging profile based on the updated EV needs, current grid conditions, and station constraints.
Send SetChargingProfileRequest with purpose TxProfile within 60 seconds (K17.FR.08).
Handle NotifyEVChargingScheduleRequest if the EV returns a schedule — validate against boundaries, respond Accepted or Rejected as in K15.

Note: When controlMode = DynamicControl, the CSMS SHALL send only 1 chargingSchedule in the SetChargingProfileRequest (K17.FR.19). In dynamic mode, the single schedule period is updated in real-time rather than providing a full schedule upfront.

Key Differences from K15

Aspect	K15	K17
`Trigger`	Initial session start — EV sends ChargeParameterDiscoveryReq	EV requests renegotiation mid-session
`ISO 15118-20`	Uses V2XChargingParameters	Same — uses V2XChargingParameters
`controlMode`	Present — affects profile structure	Present — affects profile structure
`K17.FR.19`	N/A	When controlMode = DynamicControl, send 1 chargingSchedule

Requirements

Req ID	CSMS Action
`K17.FR.06`	CSMS SHALL respond Accepted to NotifyEVChargingScheduleRequest when the EV schedule is within allowed boundaries
`K17.FR.07`	CSMS SHALL respond Rejected to NotifyEVChargingScheduleRequest when the EV schedule exceeds allowed boundaries
`K17.FR.08`	CSMS SHALL send SetChargingProfileRequest within 60 seconds of responding Accepted to NotifyEVChargingNeedsRequest
`K17.FR.11`	CSMS SHALL account for current grid constraints and station capacity when computing the updated profile
`K17.FR.12`	If CSMS rejects the EV schedule, CSMS SHALL initiate a new renegotiation with an updated SetChargingProfileRequest
`K17.FR.19`	When controlMode = DynamicControl, CSMS SHALL send only 1 chargingSchedule in the SetChargingProfileRequest

14. K18 — ISO 15118-20 Scheduled Control Mode

ISO 15118-20

Use Case ID	K18
Direction	Bidirectional
Trigger	EV and CS support ISO 15118-20 Scheduled Control Mode
OCPP Messages	NotifyEVChargingNeedsReq/Res + SetChargingProfileReq/Res + NotifyEVChargingScheduleReq/Res

Sequence Diagram

K18 — ISO 15118-20 Scheduled Control Mode

EV              Charging Station                              CSMS
 |                       |                                       |
 |--ScheduleExchangeReq->|                                       |
 |  (controlMode=        |                                       |
 |   ScheduledControl)   |                                       |
 |                       |--- NotifyEVChargingNeedsReq --------->|
 |                       |    (controlMode=ScheduledControl,     |
 |                       |     v2xChargingParameters)            |
 |                       |<-- NotifyEVChargingNeedsRes ----------|
 |                       |    (status=Accepted/Processing/       |
 |                       |     NoChargingProfile/Rejected)       |
 |                       |                                       |
 |                       |<-- SetChargingProfileReq -------------|
 |                       |    (up to 3 schedules +               |
 |                       |     price schedules)                  |
 |                       |--- SetChargingProfileRes ------------>|
 |                       |                                       |
 | <-ScheduleExchangeRes-|                                       |
 |   (up to 3 schedules  |                                       |
 |   + price schedules)  |                                       |
 |                       |                                       |
 |--PowerDeliveryReq---> |                                       |
 |  (selectedScheduleId) |                                       |
 | <--PowerDeliveryRes---|                                       |
 |                       |                                       |
 |                       |--- NotifyEVChargingScheduleReq ------>|
 |                       |    (selectedChargingScheduleId)       |
 |                       |<-- NotifyEVChargingScheduleRes -------|

Handling NotifyEVChargingNeedsRequest

In K18, the controlMode will be ScheduledControl and chargingNeeds will contain v2xChargingParameters (NOT acChargingParameters or dcChargingParameters).

Response Status Values

Status	Meaning
`Accepted`	CSMS will provide charging schedules. Follow up with SetChargingProfileRequest within 60 seconds.
`NoChargingProfile`	CSMS will NOT provide a charging profile. Differs from K15 Rejected — station uses TxDefaultProfile or max EVSE power.
`Processing`	CSMS needs more time to compute. Will send SetChargingProfileRequest later.
`Rejected`	CSMS rejects the requestedEnergyTransfer (K18.FR.22). The station SHALL terminate charging.

Important: In K18, Rejected means the CSMS rejects the requestedEnergyTransfer entirely (K18.FR.22). The Charging Station SHALL terminate charging (K18.FR.23). Use NoChargingProfile instead when the CSMS simply does not wish to provide a schedule.

Sending SetChargingProfileRequest

The CSMS can include up to 3 charging schedules along with price schedules (absolutePriceSchedule or priceLevelSchedule) for ISO 15118-20.

SetChargingProfileRequest — K18 Example with absolutePriceSchedule

{
  "evseId": 1,
  "chargingProfile": {
    "id": 200,
    "stackLevel": 1,
    "chargingProfilePurpose": "TxProfile",
    "chargingProfileKind": "Absolute",
    "transactionId": "tx-iso20-001",
    "chargingSchedule": [
      {
        "id": 1,
        "chargingRateUnit": "W",
        "chargingSchedulePeriod": [
          { "startPeriod": 0, "limit": 11000 },
          { "startPeriod": 3600, "limit": 22000 },
          { "startPeriod": 7200, "limit": 7400 }
        ],
        "startSchedule": "2025-03-15T14:00:00Z",
        "duration": 14400,
        "absolutePriceSchedule": {
          "timeAnchor": "2025-03-15T14:00:00Z",
          "priceScheduleID": 1,
          "currency": "EUR",
          "language": "en",
          "priceAlgorithm": "urn:oca:ocpp:priceAlgorithm:SpotPricing",
          "priceRuleStacks": [
            {
              "duration": 3600,
              "priceRules": [
                {
                  "energyFee": 0.25,
                  "parkingFee": 0.0,
                  "powerRangeStart": 0
                }
              ]
            },
            {
              "duration": 3600,
              "priceRules": [
                {
                  "energyFee": 0.18,
                  "parkingFee": 0.0,
                  "powerRangeStart": 0
                }
              ]
            },
            {
              "duration": 7200,
              "priceRules": [
                {
                  "energyFee": 0.30,
                  "parkingFee": 0.02,
                  "powerRangeStart": 0
                }
              ]
            }
          ]
        }
      }
    ]
  }
}

Key Differences from K15

Aspect	K15 (ISO 15118-2)	K18 (ISO 15118-20)
Charging parameters	acChargingParameters / dcChargingParameters	v2xChargingParameters (K18.FR.06)
controlMode	Absent (implied scheduled)	ScheduledControl (explicit)
Reject status	Rejected = will not provide schedule	NoChargingProfile = will not provide schedule (K18.FR.04)
Reject energy transfer	N/A	Rejected = station terminates charging (K18.FR.22 / K18.FR.23)
Price schedules	salesTariff only	absolutePriceSchedule or priceLevelSchedule
Timeout reference	ChargeParameterDiscoveryReq (60s)	ScheduleExchangeReq (60s) — K18.FR.08
Period limit	maxScheduleTuples + PeriodsPerSchedule	Same, but also applies to price rule entries

Requirements

Req ID	CSMS Action
`K18.FR.04`	CSMS SHALL respond with NoChargingProfile (not Rejected) when it will not provide a charging schedule
`K18.FR.06`	CSMS SHALL use v2xChargingParameters from the chargingNeeds (not ac/dcChargingParameters)
`K18.FR.07`	CSMS SHALL send SetChargingProfileRequest with chargingProfilePurpose = TxProfile and up to 3 chargingSchedule entries
`K18.FR.08`	CSMS SHALL send the SetChargingProfileRequest within 60 seconds (ScheduleExchangeReq timeout) if status was Accepted or Processing
`K18.FR.18`	CSMS SHALL respect maxScheduleTuples for both schedule periods and price rule entries
`K18.FR.22`	CSMS SHALL respond with Rejected if it cannot support the requestedEnergyTransfer mode
`K18.FR.23`	When CSMS responds Rejected, the Charging Station SHALL terminate charging

15. K19 — ISO 15118-20 Dynamic Control Mode

ISO 15118-20

Use Case ID	K19
Direction	Bidirectional
Trigger	EV and CS support ISO 15118-20 Dynamic Control Mode
OCPP Messages	NotifyEVChargingNeedsReq/Res + SetChargingProfileReq/Res + NotifyEVChargingScheduleReq/Res

Key Concept

How Dynamic Control Mode Differs

CSMS sends ONE charging schedule (not up to three).
CS does NOT send charging schedules to the EV — only a price schedule (if any).
CS dynamically controls the EV's charging rate to match the CSMS profile.
EV returns an EVPowerProfile but the station IGNORES it.
The NotifyEVChargingScheduleRequest contains the CSMS's charging schedule (not the EV's selected schedule).

Sequence Diagram

K19 — ISO 15118-20 Dynamic Control Mode

EV              Charging Station                              CSMS
 |                      |                                       |
 |--ScheduleExchangeReq->|                                       |
 |  (controlMode=        |                                       |
 |   DynamicControl)     |                                       |
 |                      |--- NotifyEVChargingNeedsReq --------->|
 |                      |    (controlMode=DynamicControl,        |
 |                      |     v2xChargingParameters)             |
 |                      |<-- NotifyEVChargingNeedsRes ----------|
 |                      |    (status=Accepted/Processing/        |
 |                      |     NoChargingProfile/Rejected)        |
 |                      |                                       |
 |                      |<-- SetChargingProfileReq -------------|
 |                      |    (1 schedule + optional price)       |
 |                      |--- SetChargingProfileRes ------------>|
 |                      |                                       |
 |<-ScheduleExchangeRes-|                                       |
 |  (price schedule only,|                                       |
 |   NO charging sched)  |                                       |
 |                      |                                       |
 |--EVPowerProfile------>|  [station IGNORES this]               |
 |                      |                                       |
 |                      |--- NotifyEVChargingScheduleReq ------>|
 |                      |    (CSMS schedule, NOT EV schedule)    |
 |                      |<-- NotifyEVChargingScheduleRes -------|
 |                      |                                       |
 |  [CS dynamically      |                                       |
 |   controls EV rate    |                                       |
 |   via ChargeLoopReq/  |                                       |
 |   ChargeLoopRes]      |                                       |

Sending SetChargingProfileRequest

The CSMS sends exactly one charging schedule. The key constraint is that only ONE chargingSchedule entry is allowed in the profile.

SetChargingProfileRequest — K19 Example

{
  "evseId": 1,
  "chargingProfile": {
    "id": 300,
    "stackLevel": 1,
    "chargingProfilePurpose": "TxProfile",
    "chargingProfileKind": "Absolute",
    "transactionId": "tx-iso20-dyn-001",
    "chargingSchedule": [
      {
        "id": 1,
        "chargingRateUnit": "W",
        "chargingSchedulePeriod": [
          { "startPeriod": 0, "limit": 11000 },
          { "startPeriod": 1800, "limit": 7400 },
          { "startPeriod": 3600, "limit": 22000 },
          { "startPeriod": 7200, "limit": 11000 }
        ],
        "startSchedule": "2025-03-15T14:00:00Z",
        "duration": 14400
      }
    ]
  }
}

Important: chargingProfileKind Does NOT Need to Be Dynamic

ISO 15118-20 "dynamic control mode" does NOT require chargingProfileKind = Dynamic. The CSMS can send an Absolute profile with several schedule periods. The key requirement is only ONE chargingSchedule entry (K19.FR.07).

Key Differences from K18

Aspect	K18 (Scheduled)	K19 (Dynamic)
controlMode	ScheduledControl	DynamicControl
Number of schedules	Up to 3	Exactly 1 (K19.FR.07)
CS sends schedules to EV	Yes	No — CS controls EV directly
EV selects schedule	Yes (selectedChargingScheduleId)	No — CS controls the charging rate
EVPowerProfile handling	Validates against boundaries	Ignores (K19.FR.10)
NotifyEVChargingScheduleReq content	EV's selected schedule	CSMS's charging schedule
Reject status	Rejected = terminate charging	Rejected = terminate charging

Requirements

Req ID	CSMS Action
`K19.FR.04`	CSMS SHALL respond with NoChargingProfile (not Rejected) when it will not provide a charging schedule
`K19.FR.06`	CSMS SHALL use v2xChargingParameters from the chargingNeeds (not ac/dcChargingParameters)
`K19.FR.07`	CSMS SHALL send SetChargingProfileRequest with exactly ONE chargingSchedule entry
`K19.FR.08`	CSMS SHALL send the SetChargingProfileRequest within 60 seconds (ScheduleExchangeReq timeout) if status was Accepted or Processing
`K19.FR.10`	CS SHALL ignore the EVPowerProfile returned by the EV — the CSMS profile takes precedence
`K19.FR.15`	CSMS SHALL respond with Rejected if it cannot support the requestedEnergyTransfer mode
`K19.FR.16`	When CSMS responds Rejected, the Charging Station SHALL terminate charging

16. K20 — Adjusting Schedule When Energy Needs Change

ISO 15118-20

Use Case ID	K20
Direction	Bidirectional
Trigger	EV reports change in departure time or energy need
OCPP Messages	NotifyEVChargingNeedsReq/Res + SetChargingProfileReq/Res

Note: K20 covers three scenarios for adjusting the charging schedule when the EV's energy needs change mid-session. The scenario depends on whether the session uses Scheduled or Dynamic control mode, and which party (EV or CS) initiates the renegotiation.

Scenario 1: Via EV Scheduled Control Mode

K20 Scenario 1 — Scheduled Control Mode

EV              Charging Station                              CSMS
 |                      |                                       |
 |  [EV detects changed energy needs]                           |
 |                      |                                       |
 |--ScheduleExchangeReq->|                                       |
 |  (updated needs)      |                                       |
 |                      |--- NotifyEVChargingNeedsReq --------->|
 |                      |    (updated departureTime /            |
 |                      |     evTargetEnergyRequest)             |
 |                      |<-- NotifyEVChargingNeedsRes ----------|
 |                      |                                       |
 |                      |<-- SetChargingProfileReq -------------|
 |                      |--- SetChargingProfileRes ------------>|
 |                      |                                       |
 |<-ScheduleExchangeRes-|                                       |
 |  (updated schedules)  |                                       |
 |                      |                                       |
 |--PowerDeliveryReq--->|                                       |
 |  (EVPowerProfile)     |                                       |
 |<--PowerDeliveryRes---|                                       |
 |                      |                                       |
 |                      |--- NotifyEVChargingScheduleReq ------>|
 |                      |<-- NotifyEVChargingScheduleRes -------|

Scenario 2: Via EV Dynamic Control Mode

K20 Scenario 2 — EV Dynamic Control Mode

EV              Charging Station                              CSMS
 |                      |                                       |
 |  [EV detects changed energy needs during charge loop]        |
 |                      |                                       |
 |--ChargeLoopReq------>|                                       |
 |  (updated needs in    |                                       |
 |   BPT parameters)     |                                       |
 |                      |--- NotifyEVChargingNeedsReq --------->|
 |                      |    (updated departureTime /            |
 |                      |     evTargetEnergyRequest)             |
 |                      |<-- NotifyEVChargingNeedsRes ----------|
 |                      |                                       |
 |                      |<-- SetChargingProfileReq -------------|
 |                      |--- SetChargingProfileRes ------------>|
 |                      |                                       |
 |<--ChargeLoopRes------|                                       |

Scenario 3: Via Charging Station Dynamic Control Mode

K20 Scenario 3 — CS Dynamic Control Mode

EV              Charging Station                              CSMS
 |                      |                                       |
 |--ChargeLoopReq------>|                                       |
 |<--ChargeLoopRes------|                                       |
 |                      |                                       |
 |  [EV reports changed needs via ChargeLoop]                   |
 |                      |                                       |
 |                      |--- NotifyEVChargingNeedsReq --------->|
 |                      |    (updated departureTime /            |
 |                      |     evTargetEnergyRequest)             |
 |                      |<-- NotifyEVChargingNeedsRes ----------|
 |                      |                                       |
 |                      |<-- SetChargingProfileReq -------------|
 |                      |--- SetChargingProfileRes ------------>|
 |                      |                                       |
 |--ChargeLoopReq------>|                                       |
 |<--ChargeLoopRes------|                                       |
 |  [CS applies updated  |                                       |
 |   limits dynamically] |                                       |

CSMS Implementation (All Scenarios)

Receive NotifyEVChargingNeedsRequest with updated departureTime and/or evTargetEnergyRequest in the v2xChargingParameters.
Calculate a new charging profile accommodating the changed needs, considering current grid constraints, energy pricing, and remaining session time.
Send SetChargingProfileRequest with the updated profile. The number of schedules depends on the control mode:
- Scheduled control: up to 3 schedules (K18 rules)
- Dynamic control: exactly 1 schedule (K19 rules)
Handle the SetChargingProfileResponse normally — if Rejected, review profile constraints and retry if appropriate.

Key point: The CSMS processing logic is identical regardless of which scenario triggered the update. The only difference is the ISO 15118 message flow between the EV and CS, which is transparent to the CSMS. The CSMS always receives a NotifyEVChargingNeedsRequest and responds with a new SetChargingProfileRequest.

17. Message Schemas Reference

Reference

Incoming Messages (CS → CSMS)

NotifyChargingLimitRequest

Field	Type	Required	Description
`chargingLimit`	ChargingLimitType	Yes	The external charging limit information
`chargingLimit.chargingLimitSource`	string (max 20)	Yes	Source of the limit (e.g., EMS, SO, Other). SHALL NOT be CSO.
`chargingLimit.isLocalGeneration`	boolean	No	true if limit is due to local generation (extra capacity, not a limitation)
`chargingLimit.isGridCritical`	boolean	No	true if the limit is critical to grid stability
`evseId`	integer (>=0)	No	EVSE the limit applies to. 0 or absent = entire station.
`chargingSchedule`	ChargingScheduleType[]	No	Charging schedules associated with the limit (if EnableNotifyChargingLimitWithSchedules is true)

ClearedChargingLimitRequest

Field	Type	Required	Description
`chargingLimitSource`	string (max 20)	Yes	Source of the limit being cleared (e.g., EMS, SO, Other)
`evseId`	integer (>=0)	No	EVSE the limit applied to. 0 or absent = entire station.

NotifyEVChargingNeedsRequest

Field	Type	Required	Description
`evseId`	integer (>=1)	Yes	The EVSE the EV is connected to
`chargingNeeds`	ChargingNeedsType	Yes	The EV's charging requirements
`chargingNeeds.requestedEnergyTransfer`	EnergyTransferModeEnumType	Yes	Requested energy transfer mode (AC_single_phase, DC, DC_BPT, etc.)
`chargingNeeds.departureTime`	dateTime	No	Estimated departure time
`chargingNeeds.controlMode`	ControlModeEnumType	No	ScheduledControl or DynamicControl (absent for ISO 15118-2)
`chargingNeeds.acChargingParameters`	ACChargingParametersType	No	ISO 15118-2 AC parameters
`chargingNeeds.dcChargingParameters`	DCChargingParametersType	No	ISO 15118-2 DC parameters
`chargingNeeds.v2xChargingParameters`	V2XChargingParametersType	No	ISO 15118-20 V2X parameters
`chargingNeeds.evEnergyOffer`	EVEnergyOfferType	No	EV's energy offer for V2X
`maxScheduleTuples`	integer (>=0)	No	Max number of schedule entries the EV supports
`timestamp`	dateTime	No	When the needs were received (useful if CS was offline)

NotifyEVChargingScheduleRequest

Field	Type	Required	Description
`timeBase`	dateTime	Yes	Reference time for the schedule periods
`evseId`	integer (>=1)	Yes	The EVSE to which this schedule applies
`chargingSchedule`	ChargingScheduleType	Yes	The EV's charging schedule (K15/K18) or CSMS schedule (K19)
`selectedChargingScheduleId`	integer (>=0)	No	ID of the schedule the EV selected (K18 Scheduled mode only)
`powerToleranceAcceptance`	boolean	No	true if EV accepts the power tolerance

Outgoing Messages (CSMS → CS)

NotifyChargingLimitResponse

Empty body — the CSMS simply acknowledges receipt. Only optional customData may be included.

ClearedChargingLimitResponse

Empty body — the CSMS simply acknowledges receipt. Only optional customData may be included.

NotifyEVChargingNeedsResponse

Field	Type	Required	Description
`status`	NotifyEVChargingNeedsStatusEnumType	Yes	Accepted, Rejected, Processing, or NoChargingProfile
`statusInfo`	StatusInfoType	No	Additional status details

NotifyEVChargingScheduleResponse

Field	Type	Required	Description
`status`	GenericStatusEnumType	Yes	Accepted (within limits) or Rejected (exceeds boundaries)
`statusInfo`	StatusInfoType	No	Additional status details

SetChargingProfileRequest

Field	Type	Required	Description
`evseId`	integer (>=0)	Yes	EVSE to apply the profile to. 0 = entire station.
`chargingProfile`	ChargingProfileType	Yes	The charging profile to install

Key ChargingProfileType Fields

Field	Type	Required	Description
`id`	integer	Yes	Unique profile identifier
`stackLevel`	integer (>=0)	Yes	Priority level in the stack (higher = higher priority)
`chargingProfilePurpose`	enum	Yes	TxProfile, TxDefaultProfile, ChargingStationMaxProfile, etc.
`chargingProfileKind`	enum	Yes	Absolute, Relative, Recurring, or Dynamic
`transactionId`	string (max 36)	Conditional	Required when chargingProfilePurpose = TxProfile
`chargingSchedule`	ChargingScheduleType[1..3]	Yes	1 to 3 charging schedules (K19 dynamic = exactly 1)

SetChargingProfileResponse

Field	Type	Required	Description
`status`	ChargingProfileStatusEnumType	Yes	Accepted or Rejected
`statusInfo`	StatusInfoType	No	Additional status details

ClearChargingProfileRequest

Field	Type	Required	Description
`chargingProfileId`	integer	No	Specific profile ID to clear
`chargingProfileCriteria`	ClearChargingProfileType	No	Criteria to match profiles for clearing
`chargingProfileCriteria.evseId`	integer (>=0)	No	EVSE to clear profiles from
`chargingProfileCriteria.chargingProfilePurpose`	enum	No	Purpose of profiles to clear
`chargingProfileCriteria.stackLevel`	integer (>=0)	No	Stack level of profiles to clear

ClearChargingProfileResponse

Field	Type	Required	Description
`status`	ClearChargingProfileStatusEnumType	Yes	Accepted (profiles cleared) or Unknown (no matching profiles found)
`statusInfo`	StatusInfoType	No	Additional status details

18. Configuration Variables Reference

Reference

Variable	Description	Relevance
`LimitChangeSignificance`	Threshold for when CS reports limit/rate changes.	Determines when NotifyChargingLimitRequest and TransactionEventRequest (trigger=ChargingRateChanged) are sent
`EnableNotifyChargingLimitWithSchedules`	When true, CS includes charging schedules in NotifyChargingLimitRequest.	Affects whether CSMS receives schedule data alongside external limits
`ExternalControlSignalsEnabled`	When true, external control system signals are enabled.	Required for K14, K23-K27
`ExternalConstraintsProfileDisallowed`	When true, CS ignores external charging limits.	CSMS must use operationMode = ExternalLimits (K29) instead
`MaxExternalConstraintsId`	Maximum ID value for external constraints profiles.	Used to avoid ID clashes between CSMS and external profiles
`SmartChargingCtrlr.PeriodsPerSchedule`	Max number of schedule periods per schedule.	Limits the number of chargingSchedulePeriod entries CSMS can include

Quick Reference Decision Trees

1. When receiving NotifyChargingLimitRequest

Store the external limit information — record chargingLimitSource, evseId, and any associated chargingSchedule.
Respond with an empty NotifyChargingLimitResponse.
Check isLocalGeneration — if true, this represents extra capacity available from local generation, not a limitation.
Check isGridCritical — if true, this limit is critical to grid stability and should be prioritized.
Update internal state and factor the limit into future charging profile calculations.

2. When receiving NotifyEVChargingNeedsRequest

Check controlMode:
- Absent or ScheduledControl → K15/K17/K18 flow (scheduled mode)
- DynamicControl → K19 flow (dynamic mode, exactly 1 schedule)
Check charging parameters — use acChargingParameters/dcChargingParameters for ISO 15118-2 or v2xChargingParameters for ISO 15118-20.
Check requestedEnergyTransfer — if unsupported, respond with Rejected (K18.FR.22/K19.FR.15).
Calculate the optimal charging profile considering EV needs, grid constraints, pricing, and maxScheduleTuples.
Respond with the appropriate status (Accepted, Processing, NoChargingProfile, or Rejected).
Send SetChargingProfileRequest within 60 seconds if status was Accepted or Processing.

3. When receiving NotifyEVChargingScheduleRequest

Compare the EV's charging schedule against the boundaries defined in the CSMS's charging profile.
If within limits — respond with Accepted. The EV's schedule is acceptable and charging proceeds normally.
If NOT within limits — respond with Rejected. This triggers K16 renegotiation — send a new SetChargingProfileRequest with updated limits.

4. When receiving ClearedChargingLimitRequest

Clear the stored external limit for the specified chargingLimitSource and evseId.
Respond with an empty ClearedChargingLimitResponse.
Update internal state — the external constraint is now removed. Optionally send updated charging profiles to take advantage of the freed capacity.