OCPP 2.1 Edition 2 Section K

Smart Charging Flows - CSMS Developer Guide

Based on OCPP 2.1 Edition 2 Specification (Part 2), Section K (Smart Charging). This guide covers all smart charging flows (K01–K22), including charging profiles, composite schedules, load balancing, external constraints, ISO 15118 charging needs, and priority charging from the CSMS perspective using OCPP-J (JSON over WebSocket).

20 Sections
17 Use Cases
K01 – K22

1. Overview & Concepts

Introduction

Smart Charging in OCPP 2.1 enables the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS can set, update, and clear charging profiles to manage energy distribution across stations.

Types of Smart Charging

Type Description CSMS Role
Internal Load Balancing CS controls current/power per EVSE internally Set known physical grid connection limits via ChargingStationMaxProfile
Central Smart Charging CSMS controls per-EV or per-station limits Actively send TxProfile / TxDefaultProfile per transaction
Local Smart Charging A Local Controller manages a group of stations Set max limit on Local Controller; LC distributes among stations
External Smart Charging External actor (DSO, EMS) sets limits CS reports external limits to CSMS via NotifyChargingLimitRequest

Charging Profile Purposes

Purpose Description evseId Persistence
ChargingStationMaxProfile Overall max power/current limit for the entire CS Always 0 Persistent
TxDefaultProfile Default schedule for new transactions 0 = all, >0 = specific Persistent
TxProfile Transaction-specific profile (overrules TxDefaultProfile) >0 only Not required
ChargingStationExternalConstraints Limits from external systems (EMS/DSO) — CSMS SHALL NOT set this 0 or >0 Not required
PriorityCharging Overrules Tx/TxDefault with max possible power, charging only >0 only Persistent
LocalGeneration Adds local generation capacity on top of other limits 0 or >0 Not required

Important: The CSMS SHALL NOT set ChargingStationExternalConstraints — this purpose is reserved for external actors (EMS/DSO) setting limits directly on the Charging Station.

Charging Profile Kind

Kind Description startSchedule
Absolute Periods relative to an absolute point in time Required
Recurring Restarts periodically (Daily/Weekly) Required
Relative Starts when EVSE ready to deliver energy Must be absent
Dynamic Single period, updated dynamically by CSMS or external actor N/A

Operation Modes (New in 2.1)

Mode Direction Description
ChargingOnly Unidirectional Default. Only limit field used
ExternalSetpoint Unidirectional setpoint determined by external actor (EMS)
ExternalLimits Unidirectional limit determined by external actor
CentralSetpoint Bidirectional setpoint set by CSMS
CentralFrequency Bidirectional Frequency-watt curve based
LocalFrequency Bidirectional Local frequency response
LocalLoadBalancing Bidirectional Local load balancing
Idle Bidirectional EVSE sleep mode

Stack Level & Profile Precedence

  • Higher stackLevel values have precedence over lower values within the same chargingProfilePurpose.
  • The Composite Schedule is calculated by taking the lowest limit and setpoint across the leading profiles from each purpose (ChargingStationMaxProfile, ChargingStationExternalConstraints, TxDefaultProfile/TxProfile/PriorityCharging).
  • LocalGeneration capacity is added on top of the calculated composite schedule.
  • PriorityCharging overrules TxProfile and TxDefaultProfile.

2. K01 — SetChargingProfile

CSMS-Initiated
Use Case ID K01
Direction CSMS → Charging Station
Objective Set or update a charging profile on the Charging Station to influence charging power/current
OCPP Messages SetChargingProfileRequest / SetChargingProfileResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)
CSMS                                    Charging Station
  |                                           |
  |  SetChargingProfileRequest(evseId,        |
  |    chargingProfile)                       |
  |------------------------------------------>|
  |                                           |
  |  SetChargingProfileResponse(status)       |
  |<------------------------------------------|

Request: SetChargingProfileRequest

CSMS sends this message to set/update a charging profile on the CS.

Field Type Required Description
evseId integer (>=0) Yes Target EVSE. 0 = entire station (for TxDefaultProfile applies to all EVSEs; for ChargingStationMaxProfile = overall limit)
chargingProfile ChargingProfileType Yes The charging profile to install

ChargingProfileType

Field Type Required Description
id integer Yes Unique ID within the CS. Can be negative (useful to distinguish from external-actor profiles)
stackLevel integer (>=0) Yes Priority level. Higher = more precedence
chargingProfilePurpose enum Yes ChargingStationMaxProfile, TxDefaultProfile, TxProfile, PriorityCharging, LocalGeneration (NOT ChargingStationExternalConstraints)
chargingProfileKind enum Yes Absolute, Recurring, Relative, Dynamic
recurrencyKind enum No Daily or Weekly. Required only when kind = Recurring
validFrom dateTime No When profile becomes valid. If absent, valid immediately
validTo dateTime No When profile expires. If absent, valid until replaced
transactionId string (max 36) Conditional Required when purpose = TxProfile. Matches profile to a specific transaction
maxOfflineDuration integer No Seconds the profile remains valid while CS is offline. 0 = immediately invalid offline
invalidAfterOfflineDuration boolean No If true, profile becomes permanently invalid after offline timeout. Default: false
chargingSchedule ChargingScheduleType[] Yes 1 to 3 charging schedules
dynUpdateInterval integer No For Dynamic profiles: seconds between update requests
dynUpdateTime dateTime No For Dynamic profiles: last update time

ChargingScheduleType

Field Type Required Description
id integer Yes Unique schedule ID
chargingRateUnit enum Yes W (Watts) or A (Amperes)
chargingSchedulePeriod Period[] Yes 1 to 1024 periods, ordered by startPeriod
startSchedule dateTime Conditional Required for Absolute and Recurring kinds. Must be absent for Relative
duration integer No Duration in seconds. If omitted, last period continues indefinitely
minChargingRate number No Minimum efficient charging rate (for local smart charging optimization)
useLocalTime boolean No If true, treat startSchedule as local time (ignoring timezone offset)
randomizedDelay integer (>=0) No Max random delay (seconds) for period starts. Only for TxProfile/TxDefaultProfile
limitAtSoC LimitAtSoCType No Cap limit/setpoint when EV SoC exceeds threshold
salesTariff SalesTariffType No ISO 15118-2 tariff information
absolutePriceSchedule AbsolutePriceScheduleType No ISO 15118-20 price schedule
priceLevelSchedule PriceLevelScheduleType No ISO 15118-20 price levels

LimitAtSoCType (New in 2.1)

Field Type Required Description
soc integer (0-100) Yes SoC threshold percentage
limit number Yes Charging rate limit to apply when SoC >= threshold

ChargingSchedulePeriodType

Field Type Required Description
startPeriod integer Yes Start of period in seconds from schedule start. First period MUST be 0
limit number Conditional Max charging rate (W or A). Required for ChargingOnly mode
limit_L2 number No Per-phase limit for L2
limit_L3 number No Per-phase limit for L3
numberPhases integer (0-3) No Number of phases. Default: 3 for AC. Omit for DC
phaseToUse integer (1-3) No Specific phase when numberPhases=1 and EVSE supports phase switching
dischargeLimit number (<=0) No Max discharge rate (negative value)
dischargeLimit_L2 number (<=0) No Per-phase discharge limit L2
dischargeLimit_L3 number (<=0) No Per-phase discharge limit L3
setpoint number No Target charge/discharge rate (negative = discharge)
setpoint_L2 number No Per-phase setpoint L2
setpoint_L3 number No Per-phase setpoint L3
setpointReactive number No Reactive power setpoint (+inductive, -capacitive)
setpointReactive_L2 number No Per-phase reactive setpoint L2
setpointReactive_L3 number No Per-phase reactive setpoint L3
operationMode enum No Operation mode for this period. Default: ChargingOnly
evseSleep boolean No If true, EVSE turns off power electronics. Only valid with operationMode = Idle
preconditioningRequest boolean No Request EV to keep BMS preconditioned

Response: SetChargingProfileResponse

The CS responds with acceptance or rejection.

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

Known Rejection Reason Codes

reasonCode Condition
TxNotFound TxProfile sent but no active transaction on the specified EVSE
UnknownEVSE The specified evseId does not exist
UnsupportedRateUnit chargingRateUnit not supported by CS
DuplicateProfile Duplicate stackLevel-purpose-evseId combination with different id
InvalidSchedule Various schedule validation failures (e.g., useLocalTime/randomizedDelay/limitAtSoC not supported)
InvalidProfile dynUpdateInterval/dynUpdateTime on non-Dynamic profile
InvalidProfileId Profile ID <= MaxExternalConstraintsId when that config var is set
InvalidOperationMode Operation mode not valid for the profile purpose or not supported
UnsupportedPurpose Profile purpose (PriorityCharging, LocalGeneration) not in SupportedAdditionalPurposes
PhaseConflict Conflicting phaseToUse between profiles
NoPhaseForDC numberPhases/phaseToUse on DC EVSE without DCInputPhaseControl
RateLimitExceeded Too many frequent updates threatening persistent memory

CSMS Implementation Rules

  1. NEVER set chargingProfilePurpose to ChargingStationExternalConstraints (K01.FR.22).
  2. ALWAYS include transactionId when setting a TxProfile (K01.FR.03).
  3. Do not create duplicate stackLevel-chargingProfilePurpose-evseId combinations with different id when purpose is NOT TxProfile (K01.FR.06).
  4. Do not create duplicate stackLevel-transactionId combinations with different id when purpose IS TxProfile (K01.FR.39).
  5. TxProfile can only be used with evseId > 0 (K01.FR.16).
  6. ChargingStationMaxProfile must NOT use chargingProfileKind = Relative (K01.FR.38).
  7. Do not set phaseToUse when numberPhases is other than 1 (K01.FR.19).
  8. For PriorityCharging: do NOT add duration to any chargingSchedule (K01.FR.73), and operationMode must be ChargingOnly (K01.FR.71).
  9. When MaxExternalConstraintsId is configured, choose profile id values higher than that value (K01.FR.80).
  10. Support maxOfflineDuration > 0 and invalidAfterOfflineDuration = true/false (K01.FR.104).
  11. Support limitAtSoC in charging schedules (K01.FR.105).
  12. Support useLocalTime = true and randomizedDelay > 0 (K01.FR.96).
  13. Only provide limit_L2/limit_L3 in TxProfile and only after receiving NotifyEVChargingNeedsRequest with per-phase max power values (K01.FR.142-145).
  14. If CS responds with RateLimitExceeded, use the delay from statusInfo.additionalInfo before retrying (K01.FR.58-59).

Examples

SetChargingProfileRequest — TxDefaultProfile (Daily Recurring) 
{
  "evseId": 0,
  "chargingProfile": {
    "id": 100,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxDefaultProfile",
    "chargingProfileKind": "Recurring",
    "recurrencyKind": "Daily",
    "chargingSchedule": [{
      "id": 1,
      "startSchedule": "2013-01-01T00:00:00Z",
      "duration": 86400,
      "chargingRateUnit": "W",
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 11000, "numberPhases": 3 },
        { "startPeriod": 28800, "limit": 6000, "numberPhases": 3 },
        { "startPeriod": 72000, "limit": 11000, "numberPhases": 3 }
      ]
    }]
  }
}
SetChargingProfileRequest — TxProfile for Specific Transaction 
{
  "evseId": 1,
  "chargingProfile": {
    "id": 200,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxProfile",
    "chargingProfileKind": "Relative",
    "transactionId": "TX-ABC-12345",
    "chargingSchedule": [{
      "id": 1,
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 32, "numberPhases": 3 }
      ]
    }]
  }
}

3. K02 — Central Smart Charging

CSMS-Initiated
Use Case ID K02
Direction CSMS → Charging Station (ongoing transaction management)
Objective CSMS dynamically adjusts charging limits per transaction based on grid constraints, energy prices, etc.
OCPP Messages SetChargingProfileRequest / SetChargingProfileResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)
EV Driver    EV    Charging Station                          CSMS
   |          |          |                                     |
   |  plugin  |          |                                     |
   |--------->|          |                                     |
   |          |  auth    |                                     |
   |          |--------->|                                     |
   |          |          | TransactionEventRequest(Started)    |
   |          |          |----------------------------------->|
   |          |          | TransactionEventResponse(...)       |
   |          |          |<-----------------------------------|
   |          |          |                                     |
   |          |  charge  |                                     |
   |          |<---------|                                     |
   |          |          |          [CSMS decides to change]   |
   |          |          |                                     |
   |          |          | SetChargingProfileRequest(TxProfile)|
   |          |          |<-----------------------------------|
   |          |          | SetChargingProfileResponse(Accepted)|
   |          |          |----------------------------------->|

CSMS Implementation Steps

  1. Receive TransactionEventRequest with eventType = Started from the CS.
  2. Decide whether to set charging limits for this transaction.
  3. Send SetChargingProfileRequest with:
    • chargingProfilePurpose = TxProfile
    • transactionId = the transaction ID from the TransactionEventRequest
    • chargingProfileKind = Relative (recommended — starts when charging begins)
  4. Process SetChargingProfileResponse.
  5. Repeat step 3 any time limits need to change during the transaction.

CSMS Requirements

Requirement Description
K02.FR.01 Use charging profiles that stay within limits imposed by any external system
K02.FR.03 Set chargingProfilePurpose to TxProfile for transaction-specific profiles
K02.FR.07 Do NOT set chargingProfilePurpose to ChargingStationExternalConstraints

Recommendations

  • Check the offline flag in TransactionEventRequest before sending a charging profile (the transaction might have been cached while offline).
  • Omit duration in TxProfile so the profile lasts for the entire transaction.

4. K03 — Local Smart Charging

Local Controller
Use Case ID K03
Objective Illustrate local load-balancing by a Local Controller
CSMS Role Limited — set max limit on Local Controller, optionally set TxDefaultProfile

CSMS Role

The CSMS's role in local smart charging is limited:

  1. Set the maximum current for the Local Controller cluster by sending a SetChargingProfileRequest with chargingProfilePurpose = ChargingStationMaxProfile to the Local Controller (LC).
  2. Optionally set TxDefaultProfile on the LC for default per-transaction limits.
  3. Forward TransactionEventRequest messages from stations in the cluster (received via the LC).
  4. Set chargingPriority in TransactionEventResponse if certain transactions should be prioritized.

CSMS Requirements

Requirement Description
K03.FR.05 If chargingPriority is given in TransactionEventResponse that differs from the IdToken's priority, use the response value for that transaction only
K03.FR.06 Default chargingPriority = 0 when unknown

5. K04 — Internal Load Balancing

CSMS-Initiated
Use Case ID K04
Objective CS handles internal load balancing; CSMS sets the overall limit
CSMS Role Set ChargingStationMaxProfile with the grid connection limit

CSMS Role

Send SetChargingProfileRequest with:

  • evseId = 0
  • chargingProfilePurpose = ChargingStationMaxProfile
  • limit = maximum current/power of the grid connection

CSMS Requirements

Requirement Description
K04.FR.03 ChargingStationMaxProfile can only be set at evseId = 0
K04.FR.05 Combined energy flow of all EVSEs SHALL NOT exceed ChargingStationMaxProfile + LocalGeneration

6. K05 — Remote Start Transaction with Charging Profile

CSMS-Initiated
Use Case ID K05
Direction CSMS → Charging Station
Objective Remotely start a transaction with a pre-set charging profile
OCPP Messages RequestStartTransactionRequest / RequestStartTransactionResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)
External Trigger    CSMS                           Charging Station
      |               |                                  |
      | remote start  |                                  |
      |-------------->|                                  |
      |               | RequestStartTransactionRequest   |
      |               |  (idToken, chargingProfile,      |
      |               |   remoteStartId=123)             |
      |               |--------------------------------->|
      |               | RequestStartTransactionResponse  |
      |               |  (status=Accepted)               |
      |               |<---------------------------------|
      |               |                                  |
      |               |      [EV plugs in, auth, start]  |
      |               |                                  |
      |               | TransactionEventRequest(Started, |
      |               |   remoteStartId=123)             |
      |               |<---------------------------------|

CSMS Implementation

  1. Include a ChargingProfile in the RequestStartTransactionRequest.
  2. The profile's chargingProfilePurpose MUST be TxProfile (K05.FR.02).
  3. transactionId cannot be provided in the ChargingProfile (it's not known yet at request time).
  4. The CS will apply the profile once the transaction starts.

CSMS Requirements

Requirement Description
K05.FR.01 CSMS MAY include a ChargingProfile in the remote start request
K05.FR.02 Purpose SHALL always be TxProfile

7. K06 — Offline Behavior During Transaction

CS Behavior

Use Case ID: K06 — Ensure CS continues using the charging profile when it goes offline during a transaction. This is primarily a CS behavior. The CSMS should pre-configure profiles for offline scenarios.

CSMS Role

  1. Pre-set charging profiles before the CS might go offline.
  2. Use maxOfflineDuration to control how long the profile remains valid while offline.
  3. Set invalidAfterOfflineDuration = true if the profile should be permanently invalidated after the offline timeout.
  4. After reconnection, consider sending updated profiles to replace any that may have expired.

Offline Duration Settings

  • maxOfflineDuration = 0 — profile is immediately invalid when offline
  • maxOfflineDuration absent — no offline timeout, profile always valid
  • invalidAfterOfflineDuration = true — permanently invalid after timeout
  • invalidAfterOfflineDuration = false (default) — becomes valid again when back online

8. K07 — Offline Behavior at Start of Transaction

CS Behavior

Use Case ID: K07 — Ensure transactions started while offline use appropriate charging profiles.

CSMS Role

  1. Pre-install TxDefaultProfile on stations that may go offline. The CS will use these profiles for any transaction started while offline.
  2. These profiles are persistent across reboots (K01.FR.27).

Important: TxDefaultProfile is the only way to ensure transactions started while offline have appropriate charging limits. Make sure to pre-install these profiles on all stations that may experience connectivity issues.

9. K08 — Get Composite Schedule

CSMS-Initiated
Use Case ID K08
Direction CSMS → Charging Station
Objective Request the CS to report its calculated composite charging schedule
OCPP Messages GetCompositeScheduleRequest / GetCompositeScheduleResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)
CSMS                                    Charging Station
  |                                           |
  |  GetCompositeScheduleRequest(evseId,      |
  |    duration, [chargingRateUnit])          |
  |------------------------------------------>|
  |                                           | [calculate]
  |  GetCompositeScheduleResponse(status,     |
  |    [schedule])                            |
  |<------------------------------------------|

Request: GetCompositeScheduleRequest

Field Type Required Description
duration integer Yes Requested schedule length in seconds
evseId integer (>=0) Yes Target EVSE. 0 = total expected grid consumption
chargingRateUnit enum No W or A. Forces the unit of the response

Response: GetCompositeScheduleResponse

Field Type Required Description
status enum Yes Accepted or Rejected
statusInfo StatusInfoType No Additional info
schedule CompositeScheduleType No The computed schedule (present when status = Accepted)

CompositeScheduleType

Field Type Required Description
evseId integer (>=0) Yes The EVSE this schedule applies to
duration integer Yes Duration of the schedule in seconds
scheduleStart dateTime Yes Start time of the schedule
chargingRateUnit enum Yes W or A
chargingSchedulePeriod Period[] Yes The computed periods

CSMS Implementation Notes

  • The composite schedule represents the merged result of all active profiles and local limits.
  • K08.FR.04: The schedule always reports the lowest limit and setpoint when charging, and the highest dischargeLimit and setpoint when discharging.
  • When evseId = 0, the CS calculates total expected grid consumption.
  • The schedule is only indicative for that point in time and may change.
  • CS may respond Rejected if the evseId is unknown or the chargingRateUnit is not supported.

10. K09 — Get Charging Profiles

CSMS-Initiated
Use Case ID K09
Direction CSMS → CS (request), then CS → CSMS (reports)
Objective Retrieve charging profiles installed on a CS
OCPP Messages GetChargingProfilesRequest / GetChargingProfilesResponse, then ReportChargingProfilesRequest / ReportChargingProfilesResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)
CSMS                                    Charging Station
  |                                           |
  |  GetChargingProfilesRequest(requestId,    |
  |    chargingProfile filter, [evseId])      |
  |------------------------------------------>|
  |                                           |
  |  GetChargingProfilesResponse(status)      |
  |<------------------------------------------|
  |                                           |
  |  [loop while tbc = true]                  |
  |  ReportChargingProfilesRequest(           |
  |    requestId, profiles, tbc, evseId)      |
  |<------------------------------------------|
  |                                           |
  |  ReportChargingProfilesResponse()         |
  |------------------------------------------>|

Request: GetChargingProfilesRequest

Field Type Required Description
requestId integer Yes Reference ID to correlate with ReportChargingProfilesRequest
evseId integer (>=0) No 0 = station-level profiles only. Omitted = all profiles. >0 = specific EVSE
chargingProfile CriterionType Yes Filter criteria

ChargingProfileCriterionType

Field Type Required Description
chargingProfilePurpose enum No Filter by purpose
stackLevel integer (>=0) No Filter by stack level
chargingProfileId integer[] No Filter by specific profile IDs
chargingLimitSource string[] (max 4) No Filter by limit source (e.g., "CSO", "EMS", "SO", "Other")

Response: GetChargingProfilesResponse

Field Type Required Description
status enum Yes Accepted (will send reports) or NoProfiles (nothing matches)

CSMS Implementation Notes

  • Specify filter criteria using either chargingProfileId list OR one or more of stackLevel, chargingLimitSource, chargingProfilePurpose (K09.FR.03).
  • After receiving Accepted, wait for ReportChargingProfilesRequest messages.
  • Process each ReportChargingProfilesRequest and respond with ReportChargingProfilesResponse.
  • Continue collecting until tbc = false (or omitted) in the last report.

11. K10 — Clear Charging Profile

CSMS-Initiated
Use Case ID K10
Direction CSMS → Charging Station
Objective Clear one or more charging profiles from the CS
OCPP Messages ClearChargingProfileRequest / ClearChargingProfileResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)
CSMS                                    Charging Station
  |                                           |
  |  ClearChargingProfileRequest(             |
  |    [chargingProfileId],                   |
  |    [chargingProfileCriteria])             |
  |------------------------------------------>|
  |                                           |
  |  ClearChargingProfileResponse(status)     |
  |<------------------------------------------|

Request: ClearChargingProfileRequest

All fields are optional, but the CSMS SHALL specify either chargingProfileId OR at least one field in chargingProfileCriteria (K10.FR.02).

Field Type Required Description
chargingProfileId integer No Specific profile ID to clear
chargingProfileCriteria ClearChargingProfileType No Criteria-based clearing

ClearChargingProfileType

Field Type Required Description
evseId integer (>=0) No 0 = station-level. Absent = all EVSEs
chargingProfilePurpose enum No Filter by purpose
stackLevel integer (>=0) No Filter by stack level

Response: ClearChargingProfileResponse

Field Type Required Description
status enum Yes Accepted (profiles cleared) or Unknown (no matching profiles)
statusInfo StatusInfoType No Additional info

CSMS Implementation Rules

Requirement Description
K10.FR.02 CSMS SHALL specify either chargingProfileId OR at least one field in chargingProfileCriteria
K10.FR.06 CSMS SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints or LocalGeneration
K10.FR.07 When clearing TxDefaultProfile, active transactions continue as if no TxDefaultProfile was ever set
K10.FR.08/09 CS will respond Unknown if only external constraint profiles match

12. K11 — Notify Charging Limit

CS-Initiated
Use Case ID K11
Direction Charging Station → CSMS
Objective CS informs CSMS about charging limits set by an external source (EMS, DSO)
OCPP Messages NotifyChargingLimitRequest / NotifyChargingLimitResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)
Charging Station                          CSMS
      |                                     |
      | NotifyChargingLimitRequest(         |
      |   chargingLimit, [chargingSchedule],|
      |   [evseId])                         |
      |----------------------------------->|
      |                                     |
      | NotifyChargingLimitResponse()       |
      |<-----------------------------------|

Request: NotifyChargingLimitRequest (received by CSMS)

Field Type Required Description
chargingLimit ChargingLimitType Yes Information about the charging limit source
chargingSchedule ChargingScheduleType[] No The actual charging schedules/limits
evseId integer (>=0) No Which EVSE. 0 or absent = entire station

ChargingLimitType

Field Type Required Description
chargingLimitSource string (max 20) Yes Source identifier: "CSO", "EMS", "SO", "Other"
isLocalGeneration boolean No true if reporting local generation capacity (not a limitation)
isGridCritical boolean No true if the limit is critical for grid stability

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

NotifyChargingLimitResponse 
{}

CSMS Implementation

  1. Store the reported external limits for the charging station.
  2. Use this information when calculating charging profiles to send to the station.
  3. Consider isGridCritical = true as requiring immediate attention.
  4. Consider isLocalGeneration = true as additional available capacity.
  5. Small changes in limit/setpoint below the LimitChangeSignificance config variable threshold may not be reported.

13. K12 — Cleared Charging Limit

CS-Initiated
Use Case ID K12
Direction Charging Station → CSMS
Objective CS informs CSMS that an externally imposed charging limit has been cleared
OCPP Messages ClearedChargingLimitRequest / ClearedChargingLimitResponse

Request: ClearedChargingLimitRequest (received by CSMS)

Field Type Required Description
chargingLimitSource string (max 20) Yes Source that was cleared: "CSO", "EMS", "SO", "Other"
evseId integer (>=0) No EVSE from which the limit was cleared

Response: Empty response (only optional customData).

ClearedChargingLimitResponse 
{}

CSMS Implementation

  1. Update internal state to reflect that the external limit from the specified source is no longer active.
  2. Optionally send updated charging profiles to the station if the CSMS was accounting for those external limits.

14. K13 — Notify EV Charging Schedule

CS-Initiated
Use Case ID K13
Direction Charging Station → CSMS
Objective CS reports the charging schedule that the EV has communicated (via ISO 15118)
OCPP Messages NotifyEVChargingScheduleRequest / NotifyEVChargingScheduleResponse

Request: NotifyEVChargingScheduleRequest (received by CSMS)

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 (only duration, chargingSchedulePeriod with startPeriod, limit, limit_L2, limit_L3 are relevant; chargingRateUnit must be W)
selectedChargingScheduleId integer (>=0) No ID of the schedule the EV selected from the provided ChargingProfile
powerToleranceAcceptance boolean No true if EV accepts the power tolerance

Response: NotifyEVChargingScheduleResponse

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

CSMS Implementation

  1. Acknowledge with Accepted to confirm the message was processed.
  2. Use this information to understand the EV's intended charging behavior.
  3. Optionally adjust charging profiles based on the EV's schedule.
  4. If the EV indicates it will use less energy than the limit allows, the composite schedule should report the EV's amount (SC.04).

15. K15/K16/K17 — Notify EV Charging Needs

CS-Initiated ISO 15118
Use Case IDs K15 (ISO 15118 based smart charging), K16 (updated needs), K17 (multi-schedule)
Direction Charging Station → CSMS
Objective CS reports EV charging needs received via ISO 15118 so CSMS can compute an optimal charging profile
OCPP Messages NotifyEVChargingNeedsRequest / NotifyEVChargingNeedsResponse

Request: NotifyEVChargingNeedsRequest (received by CSMS)

Field Type Required Description
evseId integer (>=1) Yes The EVSE the EV is connected to
chargingNeeds ChargingNeedsType Yes The EV's charging requirements
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)

ChargingNeedsType

Field Type Required Description
requestedEnergyTransfer enum Yes AC_single_phase, AC_two_phase, AC_three_phase, DC, AC_BPT, AC_BPT_DER, AC_DER, DC_BPT, DC_ACDP, DC_ACDP_BPT, WPT
departureTime dateTime No Estimated departure time
acChargingParameters ACChargingParametersType No ISO 15118-2 AC parameters
dcChargingParameters DCChargingParametersType No ISO 15118-2 DC parameters
v2xChargingParameters V2XChargingParametersType No ISO 15118-20 V2X parameters
derChargingParameters DERChargingParametersType No ISO 15118-20 DER parameters
evEnergyOffer EVEnergyOfferType No EV's energy offer for V2X
availableEnergyTransfer enum[] No Other available energy transfer modes
controlMode enum No ScheduledControl or DynamicControl
mobilityNeedsMode enum No EVCC or EVCC_SECC

ACChargingParametersType (ISO 15118-2)

Field Type Required Description
energyAmount number Yes Requested energy in Wh
evMinCurrent number Yes Min current per phase (A)
evMaxCurrent number Yes Max current per phase (A), including cable
evMaxVoltage number Yes Max voltage (V)

DCChargingParametersType (ISO 15118-2)

Field Type Required Description
evMaxCurrent number Yes Max current (A)
evMaxVoltage number Yes Max voltage (V)
evMaxPower number No Max power (W)
evEnergyCapacity number No Battery capacity (Wh)
energyAmount number No Requested energy (Wh)
stateOfCharge integer (0-100) No Current SoC %
fullSoC integer (0-100) No SoC considered fully charged
bulkSoC integer (0-100) No SoC where fast charging ends

V2XChargingParametersType (ISO 15118-20) — Key Fields

Field Description
maxChargePower / _L2 / _L3 Max charge power per phase (W)
minChargePower / _L2 / _L3 Min charge power per phase (W)
maxDischargePower / _L2 / _L3 Max discharge power per phase (W)
minDischargePower / _L2 / _L3 Min discharge power per phase (W)
maxChargeCurrent / maxDischargeCurrent DC current limits (A)
minChargeCurrent / minDischargeCurrent DC current minimums (A)
minVoltage / maxVoltage Voltage range (V)
evTargetEnergyRequest Target energy (Wh)
evMinEnergyRequest Min energy (Wh)
evMaxEnergyRequest Max energy (Wh)
evMinV2XEnergyRequest Min V2X cycling energy (Wh)
evMaxV2XEnergyRequest Max V2X cycling energy (Wh)
targetSoC Target departure SoC (0-100)

Response: NotifyEVChargingNeedsResponse

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

Status Values

Status Meaning
Accepted CSMS can meet the EV's needs. Will send a charging profile.
Processing CSMS is computing the schedule, will send profile later.
Rejected CSMS cannot meet the needs (e.g., departure time too soon).
NoChargingProfile CSMS accepted but will not send a charging profile.

CSMS Implementation

  1. Receive the EV charging needs.
  2. Compute an optimal charging schedule considering:
    • EV's energy requirements and departure time
    • Grid constraints and external limits
    • Energy prices and availability
    • maxScheduleTuples (don't exceed this in your response profile)
  3. Respond with status indicating whether you can accommodate the needs.
  4. Send a SetChargingProfileRequest with purpose TxProfile (possibly with up to 3 ChargingScheduleType elements for ISO 15118-20 multi-schedule support).
  5. If controlMode = DynamicControl, use chargingProfileKind = Dynamic with a single period that is updated dynamically.

16. K21/K22 — Use Priority Charging

CSMS-Initiated
Use Case IDs K21 (activate), K22 (deactivate)
Direction CSMS → Charging Station
Objective Request a Charging Station to apply priority charging for a specific transaction
OCPP Messages UsePriorityChargingRequest / UsePriorityChargingResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)
CSMS                                    Charging Station
  |                                           |
  |  UsePriorityChargingRequest(              |
  |    transactionId, activate)               |
  |------------------------------------------>|
  |                                           |
  |  UsePriorityChargingResponse(status)      |
  |<------------------------------------------|

Request: UsePriorityChargingRequest

Field Type Required Description
transactionId string (max 36) Yes The transaction to prioritize
activate boolean Yes true = enable priority charging, false = disable

Response: UsePriorityChargingResponse

Field Type Required Description
status enum Yes Accepted, Rejected, NoProfile
statusInfo StatusInfoType No Additional details

Status Values

Status Meaning
Accepted Priority charging activated/deactivated
Rejected Request denied
NoProfile No PriorityCharging profile is available on the CS

CSMS Implementation

  1. Pre-install a PriorityCharging profile on the CS using SetChargingProfileRequest (K01.FR.72).
  2. When priority is needed, send UsePriorityChargingRequest with activate = true.
  3. The CS will activate the pre-installed PriorityCharging profile which overrules TxProfile/TxDefaultProfile.
  4. PriorityCharging provides maximum possible power and only allows charging (no discharge).
  5. To deactivate, send with activate = false.

PriorityCharging Profile Rules

  • operationMode must be ChargingOnly only (K01.FR.71).
  • No duration in the chargingSchedule (K01.FR.73). It lasts until end of transaction.
  • The CS must support PriorityCharging purpose (check SupportedAdditionalPurposes).

17. ReportChargingProfiles

CS-Initiated
Trigger Response to GetChargingProfilesRequest (K09)
Direction Charging Station → CSMS
Objective CS reports installed charging profiles to the CSMS
OCPP Messages ReportChargingProfilesRequest / ReportChargingProfilesResponse

Request: ReportChargingProfilesRequest (received by CSMS)

Field Type Required Description
requestId integer Yes Correlates with the GetChargingProfilesRequest
chargingLimitSource string (max 20) Yes Source that installed the profile
evseId integer (>=0) Yes EVSE the profiles are installed on
chargingProfile ChargingProfileType[] Yes Array of charging profiles
tbc boolean No true = more reports coming. false/absent = this is the last report

Response: Empty response (only optional customData).

ReportChargingProfilesResponse 
{}

CSMS Implementation

  1. Collect all ReportChargingProfilesRequest messages with the matching requestId.
  2. Continue collecting until a message arrives with tbc = false or tbc absent.
  3. Store the reported profiles for internal state management.
  4. Respond with an empty ReportChargingProfilesResponse for each received message.

18. Shared Data Types Reference

Reference

StatusInfoType

Used in most responses to provide additional detail about the status.

StatusInfoType 
{
  "reasonCode": "string (max 20, required)",
  "additionalInfo": "string (max 1024, optional)"
}

CustomDataType is available in all request/response types for vendor extensions:

CustomDataType 
{
  "vendorId": "string (max 255, required)"
}

ChargingRateUnitEnumType

Value Description
W Watts — represents total power across all phases (or per-phase if L2/L3 specified)
A Amperes — represents current per phase

Important: When using W with AC charging, the CS calculates per-phase current as: Current per phase = limit / (Line Voltage × numberPhases). When using A, limits are per-phase (not the sum).

ChargingLimitSourceEnumStringType

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

19. Charging Profile Concepts & Rules

Reference

Composite Schedule Calculation

The Composite Schedule at any point in time is determined by:

  1. For each profile purpose, find the leading schedule (highest stackLevel that has a valid period).
  2. Take the minimum of limit and setpoint across all purposes (ChargingStationMaxProfile, ChargingStationExternalConstraints, TxDefaultProfile or TxProfile or PriorityCharging).
  3. If LocalGeneration is active, add its capacity on top.
  4. When PriorityCharging is activated, it overrules TxProfile/TxDefaultProfile.
  5. For numberPhases, use the lowest value from all applicable profiles.

Stacking Profiles

Multiple profiles with the same purpose can be stacked using different stackLevel values:

  • Higher stackLevel overrides lower within the same purpose.
  • Useful for complex calendars (e.g., peak hours + weekend exceptions + holiday exceptions).

Phase Conflict Avoidance

  • Do not set conflicting phaseToUse values between ChargingStationMaxProfile and TxProfile.
  • phaseToUse can only be set when numberPhases = 1.
  • The CS will reject profiles that cause phase conflicts with reasonCode = PhaseConflict.

Randomized Delays

For TxDefaultProfile and TxProfile only:

  • Set randomizedDelay to spread load changes across multiple stations.
  • The first period (startPeriod = 0) is NOT delayed.
  • The delay is calculated once at transaction start or profile submission.

Offline Validity

Setting Behavior
maxOfflineDuration = N (seconds) Profile stays valid for N seconds while offline
maxOfflineDuration absent No offline timeout, profile always valid
invalidAfterOfflineDuration = true Profile is permanently invalid after timeout
invalidAfterOfflineDuration = false (default) Profile becomes valid again when back online

Profile Persistence

Purpose Must Persist Across Reboots
ChargingStationMaxProfile Yes
TxDefaultProfile Yes
PriorityCharging Yes
TxProfile No (but MAY be)
LocalGeneration No (but MAY be)
ChargingStationExternalConstraints No (but MAY be)

20. Message Direction Summary

Reference

Outgoing from CSMS (CSMS → Charging Station)

Message CSMS Action Use Cases
SetChargingProfileRequest Send request to set/update a charging profile K01, K02, K04, K05
ClearChargingProfileRequest Send request to clear charging profiles K10
GetCompositeScheduleRequest Send request to get composite schedule K08
GetChargingProfilesRequest Send request to retrieve installed profiles K09
UsePriorityChargingRequest Send request to activate/deactivate priority charging K21, K22

Incoming to CSMS (Charging Station → CSMS)

Message CSMS Action Use Cases
NotifyChargingLimitRequest Receive and store external charging limits K11
ClearedChargingLimitRequest Receive and update cleared external limits K12
NotifyEVChargingScheduleRequest Receive and process EV charging schedule K13
NotifyEVChargingNeedsRequest Receive, compute profile, send back K15, K16, K17
ReportChargingProfilesRequest Receive and collect reported profiles K09

Responses (CSMS sends back)

Response Message Content Trigger
SetChargingProfileResponse Process Accepted/Rejected status K01 response
ClearChargingProfileResponse Process Accepted/Unknown status K10 response
GetCompositeScheduleResponse Process schedule data K08 response
GetChargingProfilesResponse Process Accepted/NoProfiles status K09 response
UsePriorityChargingResponse Process Accepted/Rejected/NoProfile status K21/K22 response
NotifyChargingLimitResponse Send empty response K11 response
ClearedChargingLimitResponse Send empty response K12 response
NotifyEVChargingScheduleResponse Send Accepted/Rejected status K13 response
NotifyEVChargingNeedsResponse Send Accepted/Rejected/Processing/NoChargingProfile K15 response
ReportChargingProfilesResponse Send empty response K09 report

OCPP 2.1 Smart Charging Flows (K01–K22) - CSMS Developer Guide. Based on OCPP 2.1 Edition 2 Specification (Part 2), Section K.