OCPP 2.1 — Use-Case Catalog (Part 2)

Purpose: A catalog of every OCPP 2.1 Part 2 use case across functional blocks A–S. For each use case it records its ID, purpose, the messages involved, and any escalation flags — a single index an AI agent can scan to find the right use case and jump to the relevant schema and deep-dive references.

Last updated: 2026-06-11

#How This Document Was Produced

This document catalogs the use cases of the OCPP 2.1 Edition 2 Part 2 specification (functional blocks A–S). Each entry is an original summary — a short restatement of what the use case does in original wording, not verbatim spec prose (the OCA specification is CC BY-ND licensed). Its dominant confidence tier is spec-knowledge for the behavioral description of each use case; the message names referenced in each entry are schema-derived, cross-referenced against the per-block schema references listed below, all mechanically extracted from the official OCA artifacts.

This catalog contains 102 escalation points marked with > **ESCALATE:** — each flags a decision the spec leaves to the operator, vendor, or grid/market context. When an AI agent encounters one, it MUST stop and ask the developer (or relevant stakeholder) to make the decision. See METHODOLOGY.md for the full confidence and escalation model.

Each catalog entry below will list:

Purpose — what the use case accomplishes.
Messages — the OCPP messages involved, linked to the per-block schema references.
Escalation flags — any decisions an AI agent must defer to a developer or stakeholder.

Companion documents:

#A. Security

#A01 — Update Charging Station Password for HTTP Basic Authentication

Deprecated in OCPP 2.1. Use B09 (Setting a new NetworkConnectionProfile) instead to manage the BasicAuthPassword. This use case remains for backwards compatibility with OCPP 1.6 deployments using Security Profile 1 or 2.

The CSMS remotely rotates the HTTP Basic Authentication password stored in the BasicAuthPassword configuration variable on the Charging Station. The CSMS sends a SetVariablesRequest targeting SecurityCtrlr.BasicAuthPassword; on an Accepted response the Charging Station disconnects and reconnects using the new credential. If the Charging Station responds with any status other than Accepted, the old credentials remain active and the CSMS must continue accepting them.

ESCALATE: POLICY-DEPENDENT — The CSO must decide the password rotation policy: frequency, entropy requirements, and whether to accept the old credential for a grace period after a rotation failure.

Messages: SetVariables (CSMS → CS)

#A02 — Update Charging Station Certificate by request of CSMS

The CSMS initiates a certificate renewal by sending a TriggerMessageRequest with requestedMessage = SignChargingStationCertificate (or SignV2GCertificate / SignV2G20Certificate for ISO 15118 certificates). The Charging Station responds by generating a new key pair, creating a Certificate Signing Request (CSR), and sending it to the CSMS via SignCertificateRequest. The CSMS (or a connected Certificate Authority) signs the certificate and delivers it back with CertificateSignedRequest. If the Charging Station has per-EVSE ISO15118Ctrlr components, the CSMS must trigger and process one CSR per EVSE.

ESCALATE: POLICY-DEPENDENT — The CSO must decide which Certificate Authority signs the certificate, the certificate validity period, and whether to require an immediate reconnect after installation to validate the new credential.

Messages: TriggerMessage (CSMS → CS), SignCertificate (CS → CSMS), CertificateSigned (CSMS → CS)

#A03 — Update Charging Station Certificate initiated by the Charging Station

The Charging Station autonomously detects that its certificate is approaching expiry and self-initiates the renewal flow without waiting for a CSMS trigger. It generates a new key pair, constructs a CSR, and sends SignCertificateRequest to the CSMS. The CSMS (or its CA) signs and returns the certificate via CertificateSignedRequest. This use case differs from A02 only in who starts the flow: the Charging Station acts proactively rather than reactively.

ESCALATE: POLICY-DEPENDENT — The CSO must decide the threshold (days before expiry) at which the Charging Station should self-trigger renewal, and whether an expired-certificate connection should be accepted in Pending state to allow certificate refresh.

Messages: SignCertificate (CS → CSMS), CertificateSigned (CSMS → CS)

#A04 — Security Event Notification

When the Charging Station detects a security-relevant condition — such as an invalid TLS certificate, a tamper attempt, an invalid firmware signature, or a connection attempt using an unknown security profile — it sends a SecurityEventNotificationRequest to the CSMS. The notification carries the event type (a well-known string from the security events list) and an optional techInfo field for additional diagnostic detail. The CSMS acknowledges with an empty response. Critical events (such as InvalidTLSVersion) that occur before a connection is established must be queued locally and sent once connectivity is restored.

Messages: SecurityEventNotification (CS → CSMS)

#A05 — Upgrade Charging Station Security Profile

The CSMS upgrades a Charging Station from a lower security profile to a higher one (e.g. Profile 1 to Profile 2, or Profile 2 to Profile 3) without interrupting normal operation. The process involves writing the new network credentials or certificates via SetVariablesRequest, then triggering a ResetRequest so the Charging Station reconnects using the new security profile. On reconnect, the Charging Station sends BootNotificationRequest and the CSMS verifies the new profile is active. Downgrade to a lower profile is rejected unless AllowSecurityProfileDowngrade is explicitly set to true.

ESCALATE: POLICY-DEPENDENT — The CSO must decide whether to allow security profile downgrade (AllowSecurityProfileDowngrade), the reset type (Immediate vs. OnIdle), and whether to place the Charging Station in Pending state during the transition.

Messages: SetVariables (CSMS → CS), Reset (CSMS → CS), BootNotification (CS → CSMS)

#B. Provisioning

#B01 — Cold Boot Charging Station

When a Charging Station powers on and has no reason to believe the CSMS is withholding acceptance, it sends BootNotificationRequest and expects an Accepted response containing the current time and the heartbeat interval. The Charging Station then sends a Heartbeat on the configured interval to keep the connection alive and synchronize its clock. If the offline period before reconnect exceeded the OfflineThreshold configuration variable, the Charging Station also sends NotifyEventRequest with variable.name = AvailabilityState for every connector; otherwise it only sends NotifyEvent for connectors whose state changed while offline.

Messages: BootNotification (CS → CSMS), Heartbeat (CS → CSMS), NotifyEvent (CS → CSMS)

#B02 — Cold Boot Charging Station - Pending

The CSMS responds to BootNotificationRequest with status Pending when it needs to perform provisioning steps — such as pushing configuration variables or a new certificate — before the Charging Station is allowed to serve drivers. The Charging Station must continue sending BootNotificationRequest at the retry interval provided in the response. While in Pending state the CSMS may exchange GetVariables, SetVariables, and other provisioning messages. Once the CSMS completes provisioning it replies to a subsequent BootNotificationRequest with Accepted.

ESCALATE: POLICY-DEPENDENT — The operator must decide which provisioning steps (configuration push, certificate update, firmware check) are mandatory before moving from Pending to Accepted.

Messages: BootNotification (CS → CSMS), GetVariables (CSMS → CS), SetVariables (CSMS → CS)

#B03 — Cold Boot Charging Station - Rejected

The CSMS responds to BootNotificationRequest with status Rejected when it does not recognize the Charging Station or its credentials are invalid. The response includes a retry interval; the Charging Station must wait at least that interval before attempting another BootNotificationRequest. The Charging Station is not authorized to perform any charging operations while in the rejected state.

ESCALATE: POLICY-DEPENDENT — The operator must define the conditions under which a boot is rejected (unknown serial number, invalid certificate, provisioning not yet complete) and whether an alert should be raised for persistent rejection.

Messages: BootNotification (CS → CSMS)

#B04 — Offline Behavior Idle Charging Station

When CSMS connectivity is lost, the Charging Station continues to operate stand-alone. On reconnection, if the offline period exceeded the OfflineThreshold configuration variable, the Charging Station sends NotifyEventRequest with variable.name = AvailabilityState for every connector to allow the CSMS to reconstruct the full state. If the offline period was shorter than the threshold, only connectors whose AvailabilityState changed during the offline period are reported. The Charging Station then resumes sending Heartbeat messages as normal.

Messages: Heartbeat (CS → CSMS), NotifyEvent (CS → CSMS)

#B05 — Set Variables

The CSMS writes one or more Device Model variable values to the Charging Station in a single SetVariablesRequest. Each element specifies a component, variable, optional attributeType (defaulting to Actual), and the new value. The Charging Station evaluates each element independently and returns a SetVariablesResponse with one SetVariableResult per element, using status codes Accepted, Rejected, UnknownComponent, UnknownVariable, or NotSupportedAttributeType. The CSMS must not exceed the ItemsPerMessageSetVariables limit per request.

Messages: SetVariables (CSMS → CS)

#B06 — Get Variables

The CSMS retrieves the current value of one or more Device Model variables from the Charging Station. The GetVariablesRequest carries a list of GetVariableData elements, each identifying a component, variable, and optional attributeType. The Charging Station returns a GetVariablesResponse with one GetVariableResult per requested element. Variables with status WriteOnly are returned with status Rejected and no value. The CSMS must not request more elements in a single call than the ItemsPerMessageGetVariables limit allows.

Messages: GetVariables (CSMS → CS)

#B07 — Get Base Report

The CSMS requests a predefined report from the Charging Station by sending GetBaseReportRequest with a reportBase type: ConfigurationInventory (all operator-settable variables and their characteristics), FullInventory (all component-variables including characteristics), or SummaryInventory (availability and problem state of the station, EVSEs, and connectors). The Charging Station acknowledges immediately with GetBaseReportResponse and then asynchronously streams the results in one or more NotifyReportRequest messages, each acknowledged by the CSMS with NotifyReportResponse. The tbc (to be continued) flag is true in all but the last part.

Messages: GetBaseReport (CSMS → CS), NotifyReport (CS → CSMS)

#B08 — Get Custom Report

The CSMS requests a filtered report by sending GetReportRequest with optional componentCriteria (a list of criteria from: Active, Available, Enabled, Problem) and/or a list of specific componentVariables. The Charging Station returns only components matching at least one criterion (logical OR). The results are streamed asynchronously as NotifyReportRequest messages. If the filter combination yields an empty result set, the Charging Station responds with status = EmptyResultSet. Multiple criteria are OR-combined, not AND-combined.

Messages: GetReport (CSMS → CS), NotifyReport (CS → CSMS)

#B09 — Setting a new NetworkConnectionProfile

Updated in OCPP 2.1. The SetNetworkProfileRequest method is deprecated and may be removed in a future release. The preferred OCPP 2.1 method is to write NetworkConfiguration component variables directly via SetVariablesRequest.

The CSMS updates the network connection parameters for a specific configuration slot on the Charging Station. The slot number must appear in the valuesList of the NetworkConfigurationPriority variable. In the legacy flow, the CSMS sends SetNetworkProfileRequest and the Charging Station stores the new profile and replies Accepted. In the new Device Model flow, the CSMS first removes the target slot from NetworkConfigurationPriority via SetVariablesRequest, then writes individual NetworkConfiguration component variables (instance = slot number), ensuring the station cannot attempt to connect using an incomplete configuration.

ESCALATE: POLICY-DEPENDENT — The operator must decide: which configuration slot to write, whether to use the deprecated SetNetworkProfile or the new SetVariables path, and whether to immediately trigger a reconnect after updating the active profile.

Messages: SetNetworkProfile (CSMS → CS, deprecated), SetVariables (CSMS → CS, preferred)

#B10 — Migrate to new CSMS

The CSMS pushes a new network connection profile (using B09) pointing to the new CSMS endpoint, then resets the Charging Station so it reconnects to the new CSMS. The Charging Station reconnects using the newly configured profile, sends BootNotificationRequest to the new CSMS, and completes the transition. If the new CSMS rejects the connection, the Charging Station falls back to the next slot in NetworkConfigurationPriority, which should still point to the original CSMS. Errors during the B09 step are non-destructive to the current active connection because the slot being written must not be in the active priority list.

ESCALATE: POLICY-DEPENDENT — The operator must coordinate the cutover timing between old and new CSMS, decide the fallback slot configuration, and confirm the new CSMS is ready to accept the station's BootNotification before triggering the reset.

Messages: SetNetworkProfile (CSMS → CS) or SetVariables (CSMS → CS), Reset (CSMS → CS), BootNotification (CS → new CSMS)

#B11 — Reset - Without Ongoing Transaction

The CSMS instructs the Charging Station to restart when no transaction is in progress. The ResetRequest carries a type of Immediate (restart as soon as possible) or OnIdle (wait until all connectors are idle). The Charging Station acknowledges with ResetResponse (status Accepted or Rejected), performs the restart, and sends BootNotificationRequest on reconnection. An Immediate reset must be acted upon without waiting for a user to unplug.

ESCALATE: POLICY-DEPENDENT — The operator must choose the reset type (Immediate vs. OnIdle) and whether to apply the reset to a specific EVSE or the entire Charging Station.

Messages: Reset (CSMS → CS), BootNotification (CS → CSMS)

#B12 — Reset - With Ongoing Transaction

The CSMS issues a ResetRequest while one or more transactions are active. For an Immediate reset, the Charging Station stops active transactions, sends the final transaction-related messages, then restarts. For an OnIdle reset, the Charging Station marks itself as unavailable for new transactions and waits until all current transactions end before restarting. The Charging Station must not start new transactions once an OnIdle reset has been accepted. After restart it sends BootNotificationRequest.

ESCALATE: POLICY-DEPENDENT — The operator must decide whether to accept the risk of abruptly ending transactions (Immediate) or delay the reset until idle (OnIdle), and how to handle EV drivers who are mid-session.

Messages: Reset (CSMS → CS), BootNotification (CS → CSMS)

#B13 — Reset - With Ongoing Transaction - Resuming Transaction

A variant of B12 in which the Charging Station is configured to resume interrupted transactions after reboot (the ResumeTransaction capability is supported). When the reset occurs mid-transaction, the Charging Station stores enough state to reconstruct the session. After restarting and sending BootNotificationRequest, if the EV is still connected, the Charging Station resumes the transaction without requiring a new authorization. The CSMS receives the continuation as part of the same transaction ID.

ESCALATE: POLICY-DEPENDENT — The operator must decide whether transaction resumption is enabled, what the maximum allowed interruption duration is before the transaction is treated as ended, and whether the driver needs to re-authorize after a reboot.

Messages: Reset (CSMS → CS), BootNotification (CS → CSMS)

#C. Authorization

#C01 — EV Driver Authorization using RFID

The baseline authorization flow: a driver presents an RFID card and the Charging Station forwards the token to the CSMS for validation before offering energy. The CSMS replies with an authorization status (and, optionally, the set of EVSEs the token is valid for and an associated group token), so the station only allows charging when the token is accepted and applicable to that EVSE. The same token that started a session can always end it locally without re-contacting the CSMS, and driver-facing messages should be shown in the configured language(s).

Messages: Authorize (CS → CSMS)

#C02 — Authorization using a start button

For simple stations without an RFID reader, charging can be triggered by a physical start button (or mechanical key, or simply by plugging in). No Authorize message is sent; instead the Charging Station opens a transaction and reports it with a TransactionEventRequest carrying an idToken of type NoAuthorization, which the CSMS cannot reject and must accept. Tokens of this type are never stored in the Authorization Cache.

Messages: TransactionEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must decide whether button-started (unauthenticated) charging is acceptable at a given site and how the resulting energy is accounted for or billed, since no driver identity is captured.

#C03 — Authorization using credit/debit card

This use case has been retired as a stand-alone authorization case in OCPP 2.1. Its objective — starting a transaction by paying with a credit or debit card — is now covered by the dedicated ad-hoc payment use cases, principally C24 (stand-alone terminal) and the locally connected terminal flows (C18 and following). Refer to those entries for the current behavior.

Messages: No dedicated message.

#C04 — Authorization using PIN-code

A station with a keypad lets the driver type a PIN (or similar key entry such as a licence-plate number) instead of presenting a card. The entered code is sent to the CSMS in an Authorize request with the token type set to KeyCode, and the CSMS responds accepting or rejecting it. PIN codes must never appear in logs, and stations are encouraged to apply brute-force protection such as increasing back-off after failed attempts.

Messages: Authorize (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator/vendor must define PIN length and brute-force countermeasures (lockout/back-off thresholds), which the spec only recommends rather than prescribes.

#C05 — Authorization for CSMS initiated transactions

When a transaction is started remotely (for example from a mobile app) for a driver who has no RFID, the CSMS supplies the identifier itself. It sends a RequestStartTransaction with a server-generated token (type Central) — which may be a single-use virtual code or a contract identifier such as an eMAID. Because the CSMS already knows this token, the Charging Station does not send an Authorize request and does not cache it; it accepts the remote start and reports the started session via TransactionEvent, echoing the token and the remote start id.

Messages: RequestStartTransaction (CSMS → CS), TransactionEvent (CS → CSMS)

#C06 — Authorization using local id type

This case demonstrates the Local token type, used when a station generates or accepts an identifier produced by a locally integrated system rather than the CSMS — the canonical example being a parking-garage ticket that doubles as the charging credential. The Charging Station forwards the locally typed token to the CSMS in an Authorize request for validation, and a separate payment kiosk later triggers the stop via the CSMS. The interface between the local payment/parking system and the CSMS is outside OCPP scope.

Messages: Authorize (CS → CSMS), TransactionEvent (CS → CSMS)

ESCALATE: VENDOR-INTEGRATION — The protocol and semantics between the local identifier source (e.g. parking kiosk/barrier) and the CSMS are not defined by OCPP and must be agreed between the site integrator and the CSMS operator.

#C07 — Authorization using Contract Certificates

ISO 15118 Plug & Charge authorization: the EV presents a contract certificate and eMAID, and the Charging Station passes the eMAID together with the certificate hash data (and, when it cannot validate the chain itself, the full PEM chain) to the CSMS in an Authorize request. The CSMS verifies the certificate chain via real-time or cached OCSP and returns both an authorization status for the eMAID and a certificate status, so the response distinguishes "certificate revoked/expired" from "identity not allowed." When offline, the station falls back to local validation (Local Authorization List, Authorization Cache, or unknown-id handling) depending on its configuration.

Messages: Authorize (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must set offline contract-validation behavior (ContractValidationOffline, CentralContractValidationAllowed, LocalAuthorizeOffline, OfflineTxForUnknownIdEnabled) and the OCSP strategy (real-time vs. cached), which together determine whether Plug & Charge works while disconnected.

#C08 — Authorization at EVSE using ISO 15118 External Identification Means (EIM)

In an ISO 15118 session where the driver authorizes by external means (EIM) rather than a contract certificate — for instance an RFID card, app, or PIN applied at the EVSE — the Charging Station sends the resulting identifier to the CSMS in an Authorize request and the CSMS responds. The mechanics are identical to the other C-block identification means; the only distinguishing factor is that 15118 communication is present. Identification may happen before plugging in or shortly after (with a bounded time-out for the latter).

Messages: Authorize (CS → CSMS)

#C09 — Authorization by GroupId

GroupId lets two drivers with different tokens act on the same session — for example a couple sharing one car, each with their own RFID card. When the CSMS authorizes a token it returns the associated groupIdToken, which the Charging Station stores alongside the token's authorization info. A second token that resolves to the same group is then allowed to stop (or otherwise act on) a transaction the first token started. The mechanism also works against the Authorization Cache, since the group id is cached too.

Messages: Authorize (CS → CSMS), TransactionEvent (CS → CSMS)

#C10 — Store Authorization Data in the Authorization Cache

The Charging Station autonomously caches the IdTokenInfo of every identifier the CSMS has responded to — whether the data arrived in an Authorize response, a TransactionEvent response, or a ReserveNow request — so that subsequent presentations can be resolved faster or while offline. Cache entries should survive reboots (non-volatile storage), expire according to AuthCacheLifeTime or the token's cacheExpiryDateTime, and the cache is enabled/disabled by AuthCacheEnabled. Personal data should be stored securely, e.g. by hashing tokens, and the additionalInfo field is not cached.

Messages: Authorize (CS → CSMS), TransactionEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must set cache lifetime (AuthCacheLifeTime) and decide on secure storage of personal data (e.g. hashing tokens), balancing offline availability against privacy/data-retention requirements.

#C11 — Clear Authorization Data in Authorization Cache

The CSMS can purge a station's Authorization Cache by sending a ClearCache request; the station attempts to clear all cached identifiers and reports the outcome. It returns Accepted on success and Rejected if it could not clear the cache or if the cache is disabled (AuthCacheEnabled is false).

Messages: ClearCache (CSMS → CS)

#C12 — Start Transaction - Cached Id

While online, a station with LocalPreAuthorize and AuthCacheEnabled set can start a transaction immediately for a token it finds cached as Accepted, skipping the Authorize round-trip for faster response. It opens the session and reports it via TransactionEvent; because that response also carries current IdTokenInfo, the station learns if the token has since become invalid and may, per MaxEnergyOnInvalidId/StopTxOnInvalidId, stop the energy offer or the transaction. Tokens belonging to the MasterPassGroupId are never allowed to start a transaction.

Messages: Authorize (CS → CSMS), TransactionEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must configure how a now-invalid cached token is handled mid-session (MaxEnergyOnInvalidId, StopTxOnInvalidId), trading faster local start against the risk of delivering energy to a token the CSMS would reject.

#C13 — Offline Authorization through Local Authorization List

When the station cannot reach the CSMS, it can still authorize a presented token by consulting the Local Authorization List — a CSMS-synchronized list of identifiers and their authorization status. If the token is present with status Accepted, charging is allowed offline. Where both a Local Authorization List and an Authorization Cache exist, list entries take priority over cache entries for the same identifier. Expiry handling depends on whether the list supports cacheExpiryDateTime and on OfflineTxForUnknownIdEnabled.

Messages: SendLocalList (CSMS → CS), GetLocalListVersion (CSMS → CS)

ESCALATE: POLICY-DEPENDENT — The operator must decide which identifiers populate the Local Authorization List and the offline policy (LocalAuthListEnabled, OfflineTxForUnknownIdEnabled), which governs who can charge when connectivity is lost.

#C14 — Online Authorization through Local Authorization List

Even while online, a station with LocalPreAuthorize enabled can authorize a token directly from the Local Authorization List without sending an Authorize request, provided the token is present with status Accepted (and any cacheExpiryDateTime has not passed). If the token is unknown or not Accepted, the station falls back to sending an Authorize request to the CSMS. As in the offline case, list entries take priority over cache entries for the same identifier.

Messages: Authorize (CS → CSMS), SendLocalList (CSMS → CS), GetLocalListVersion (CSMS → CS)

#C15 — Offline Authorization of unknown Id

This covers presenting a token the offline station has never seen — absent from both the Local Authorization List and the Authorization Cache. If OfflineTxForUnknownIdEnabled is true the station accepts the unknown token and starts charging; if false it rejects it. When connectivity returns, the station reports any such offline-authorized transaction to the CSMS, which may then confirm or reject it; on rejection the station's later behavior (continue, cap energy via MaxEnergyOnInvalidId, or stop and deauthorize) depends on StopTxOnInvalidId and the configured TxStopPoint. It applies to all identifier types, including eMAIDs from ISO 15118 contract certificates.

Messages: TransactionEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must decide, via OfflineTxForUnknownIdEnabled (and StopTxOnInvalidId/MaxEnergyOnInvalidId), whether to grant energy to wholly unknown tokens during outages, accepting the revenue/fraud risk if the CSMS later rejects them.

#C16 — Stop Transaction with a Master Pass

A Master Pass lets an authorized holder — typically law-enforcement or emergency personnel — stop ongoing transactions and release the cable. The holder presents a token whose group equals the configured MasterPassGroupId; the station validates it with the CSMS via Authorize, and the response's group id confirms Master Pass status. If the station has a UI, the holder selects which transactions to stop; otherwise all ongoing transactions are stopped. Each stopped session is reported with a TransactionEvent (Ended, stop reason MasterPass). Master Pass tokens may never start a transaction.

Messages: Authorize (CS → CSMS), TransactionEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must define and provision the MasterPassGroupId and decide who is issued Master Pass tokens, since these grant the power to terminate any driver's session.

#C17 — Authorization with prepaid card

A variant of RFID authorization (C01) for accounts carrying a prepaid balance. The station always sends an Authorize request (prepaid tokens must not be cached, so the CSMS can check the live balance) and the CSMS returns Accepted with a positive balance, NoCredit when the balance is zero/negative, or Invalid; in all cases cacheExpiryDateTime is set to now so the token does not persist in the cache. When the transaction starts, the CSMS returns a transactionLimit.maxCost equal to the remaining credit in the TransactionEvent response, and the station enforces that ceiling so no more energy is delivered than the balance covers.

Messages: Authorize (CS → CSMS), TransactionEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The CSMS operator must support prepaid accounts and define how the remaining balance maps to transactionLimit.maxCost, including any reserve/margin applied to avoid overdraw.

#C18 — Authorization using locally connected payment terminal

A driver pays with a bank card at a payment terminal built into the Charging Station. The terminal asks the Payment Service Provider (PSP) to authorize a hold for the amount in PaymentCtrlr.AuthorizationAmount, and the PSP returns an approval plus a unique reference (the PspRef). The station uses that PspRef as an idToken of type DirectPayment, with card details (card BIN, last four digits, etc.) carried in additionalInfo. If PaymentCtrlr.AuthorizeDirectPayment is false the station authorizes locally against a default ad-hoc tariff; if true it sends an Authorize request so the CSMS can accept (optionally supplying a tariff) or reject. The started transaction is reported via TransactionEvent with transactionLimit.maxCost set to the authorized hold. A VAT number entered by the driver can optionally be validated with VatNumberValidation before settlement.

Messages: Authorize (CS → CSMS), TransactionEvent (CS → CSMS), VatNumberValidation (CS → CSMS)

ESCALATE: PSP-INTEGRATION — The protocol between the integrated payment terminal and the PSP, and between the terminal and the Charging Station, is out of OCPP scope and must be defined by the terminal/station vendor and the chosen PSP.

ESCALATE: PRICING-POLICY — The operator must set the pre-authorization hold amount (PaymentCtrlr.AuthorizationAmount), the default ad-hoc tariff, and whether CSMS-side authorization (AuthorizeDirectPayment) is used to apply non-default tariffs or reject cards.

ESCALATE: REGULATORY — VAT-number handling on receipts (whether collected, validated, and printed) depends on local tax legislation and operator policy.

#C19 — Cancellation prior to transaction

After an ad-hoc payment card has been authorized but before any OCPP transaction starts — the driver cancels, or never plugs in and the EV-connection timeout fires — the held amount must be released. The payment terminal asks the PSP to release the authorization reservation, and the station ends the DirectPayment token's authorization. If PaymentCtrlr.AuthorizeDirectPayment is true (so the CSMS knew about the token), the station sends a NotifySettlement with the PspRef and status Canceled so the CSMS knows the token will not be charged; if false, the CSMS was never told about the token and receives no notification.

Messages: Authorize (CS → CSMS), NotifySettlement (CS → CSMS)

ESCALATE: PSP-INTEGRATION — Releasing the authorization hold is performed via the terminal/PSP interface, which is outside OCPP scope.

#C20 — Cancellation after start of transaction

Like C19 but the OCPP transaction has already started, though no energy was delivered and no other cost (e.g. reservation fee) was incurred. The driver cancels (or the EV-connection timeout fires); the station ends the transaction with a TransactionEvent (Ended, trigger StopAuthorized or EVConnectTimeout) reporting totalCost = 0, instructs the terminal to release the hold via the PSP, and sends a NotifySettlement with the transaction id, the DirectPayment PspRef, and status Canceled. When local cost calculation is used, the ending TransactionEvent also carries cost details showing zero cost/usage.

Messages: TransactionEvent (CS → CSMS), NotifySettlement (CS → CSMS)

ESCALATE: PSP-INTEGRATION — Releasing the authorization hold via the terminal/PSP is outside OCPP scope.

#C21 — Settlement at end of transaction

When an ad-hoc transaction ends, the final cost is settled against the held card amount and a receipt is produced. The station ends the transaction with a TransactionEvent carrying cost details, then either: (a) instructs the integrated terminal to settle the actual cost with the PSP and sends a NotifySettlement (Settled, with settlement amount/time, transaction id and PspRef, optionally VAT number/company) — the receipt URL coming back either from the CSMS in the NotifySettlement response (ReceiptByCSMS true) or from the terminal; or (b) when SettlementByCSMS is true, the CSMS settles directly with the PSP, bypassing the terminal and providing the receipt out of band. Showing a receipt is problematic when TxStopPoint is ParkingBayOccupancy, since the driver may have already left.

Messages: TransactionEvent (CS → CSMS), NotifySettlement (CS → CSMS)

ESCALATE: SETTLEMENT-CHANNEL — The operator must choose where settlement happens (terminal-to-PSP vs. CSMS-to-PSP via PaymentCtrlr.SettlementByCSMS) and who generates the receipt (ReceiptByCSMS), since these determine the money flow and reconciliation path.

ESCALATE: REGULATORY — Receipt content and delivery, including VAT number/company details and how a driver who has already left retrieves a receipt, depend on tax law and operator policy.

#C22 — Settlement is rejected or fails

Settlement of an ad-hoc payment can be declined by the PSP (Rejected) or fail for technical reasons such as a communication breakdown (Failed). In either case the station notifies the CSMS with a NotifySettlement carrying the transaction id, the DirectPayment token, settlement amount and time, the appropriate status, and optional error detail in statusInfo — but no receipt information. On failure the operator can later attempt to capture the amount by contacting the PSP directly using the PspRef (the value of the idToken).

Messages: NotifySettlement (CS → CSMS)

ESCALATE: SETTLEMENT-CHANNEL — The operator must define the recovery process for rejected/failed settlements (e.g. manual capture with the PSP via the PspRef), which OCPP only reports but does not resolve.

#C23 — Increasing authorization amount

For long or expensive ad-hoc sessions, the initial card hold (PaymentCtrlr.AuthorizationAmount) may be insufficient. If incremental authorization is supported — PaymentCtrlr.IncrementalAuthorizationAmount is greater than zero — the station monitors accrued cost and, once it approaches the current hold minus PaymentCtrlr.IncrementalAuthorizationThreshold, instructs the terminal to extend the hold by the incremental amount and raises the transaction's transactionLimit.maxCost accordingly, reporting the change in a TransactionEvent (trigger LimitChanged/LimitSet). If the incremental amount is zero or absent, energy flow halts when maxCost is reached.

Messages: TransactionEvent (CS → CSMS)

ESCALATE: PRICING-POLICY — The operator must set the incremental hold amount and threshold (PaymentCtrlr.IncrementalAuthorizationAmount, IncrementalAuthorizationThreshold), balancing uninterrupted charging against the size of the card pre-authorization.

ESCALATE: PSP-INTEGRATION — Extending the authorization hold is performed via the terminal/PSP interface, which is outside OCPP scope.

#C24 — Ad hoc payment via stand-alone payment terminal

Here the payment terminal/kiosk is a separate unit serving several Charging Stations, with no direct connection to any individual station. The driver pays at the kiosk, the kiosk gets PSP approval and a PspRef, and the kiosk forwards station/EVSE identity and card details to the CSMS. The CSMS then remotely starts the session with a RequestStartTransaction using an idToken of value <PspRef> and type DirectPayment, and the flow continues like a remote start with cost limit (F07). At the end, cost is settled — locally or centrally — and settled with the PSP either via the kiosk or directly by the CSMS, with the receipt optionally surfaced to the driver via a display message. The kiosk-to-CSMS interface is out of OCPP scope.

Messages: RequestStartTransaction (CSMS → CS), TransactionEvent (CS → CSMS)

ESCALATE: PSP-INTEGRATION — The protocol between the stand-alone kiosk and both the PSP and the CSMS is not specified by OCPP and must be defined by the kiosk/CSMS vendors.

ESCALATE: SETTLEMENT-CHANNEL — The operator must choose whether final cost is calculated locally or centrally and whether settlement with the PSP is done by the kiosk or directly by the CSMS.

#C25 — Ad hoc payment via a QR code

For stations with no payment terminal at all, ad-hoc payment can be offered through a QR code linking to a payment web page. A dynamic QR code embeds a time-based one-time password and the station/EVSE identity in a URL template (WebPaymentsCtrlr.URLTemplate); the driver scans it, the CSMS validates the one-time password, optionally sends a NotifyWebPaymentStarted so the station can block a local start during the web-payment window, then redirects the driver to the PSP. After approval the PSP returns a PspRef, and the CSMS remotely starts the session with a RequestStartTransaction using idToken <PspRef> of type DirectPayment, continuing as a remote start with cost limit. A static QR code (a sticker) works similarly but is vulnerable to a fraudulent sticker being pasted over it, so dynamic codes are recommended. Final cost is settled with the PSP by the CSMS, and a receipt URL can be pushed to the station display.

Messages: NotifyWebPaymentStarted (CSMS → CS), RequestStartTransaction (CSMS → CS), TransactionEvent (CS → CSMS)

ESCALATE: PSP-INTEGRATION — The payment web page, its URL format, the CSMS-to-PSP communication, and receipt delivery are out of OCPP scope and chosen by the operator (CSO), optionally involving an EMSP.

ESCALATE: SECURITY-POLICY — The operator must decide between static and dynamic QR codes; static stickers are susceptible to spoofing, so dynamic codes with a time-based one-time password are recommended.

#D. Local Authorization List Management

#D01 — Send Local Authorization List

The CSMS pushes a Local Authorization List to the station so that idTokens can be authorized locally — both while offline and, with pre-authorization enabled, faster while online. The SendLocalList message carries a versionNumber plus an updateType of either Full (replace the entire list) or Differential (add, update, or delete individual entries: an AuthorizationData element with idTokenInfo adds or updates it, one without removes it). The station applies the change, stores the new version number, and replies Accepted, Failed, or VersionMismatch; it rejects a differential update whose version is not strictly greater than the stored one. Each request is size-bounded by ItemsPerMessageSendLocalList/BytesPerMessageSendLocalList, so a large list is sent as an initial Full followed by Differential chunks, and the list should be held in non-volatile memory across reboots.

Messages: SendLocalList (CSMS → CS)

ESCALATE: POLICY-DEPENDENT — The operator decides which idTokens populate the list, how often it is synchronized, and whether differential or full updates are used; OCPP defines the transport but not the membership policy.

#D02 — Get Local List Version

To keep the station and CSMS lists in sync without retransmitting the whole list, the CSMS can query the station's current list version with GetLocalListVersion; the station replies with the versionNumber it currently holds. A returned value of 0 is reserved to mean "no Local Authorization List" — either because LocalAuthListEnabled is false or because the CSMS has never sent an update — whereas a list that was deliberately emptied (a SendLocalList carrying an empty list) still reports its assigned version greater than 0. The CSMS typically compares the reported version against its own and issues a SendLocalList only when they differ.

Messages: GetLocalListVersion (CSMS → CS)

#E. Transactions

#E01 — Start Transaction options

OCPP 2.1 decouples the "transaction" the CSMS records for billing from the physical charging session, and the TxStartPoint configuration variable determines the exact moment the station emits its first TransactionEvent (eventType Started). Possible start points include ParkingBayOccupancy (an occupancy detector sees the EV, trigger EVDetected), EVConnected (cable plugged in, trigger CablePluggedIn), Authorized (driver authorized), DataSigned (a signed meter reading is taken before energy flows), PowerPathClosed (authorized and connected, ready to deliver), and EnergyTransfer (energy actually starts flowing). The operator picks the start point to match what is billed — connection time, time of use, or charging time — and not all combinations of start and stop point are sensible.

Messages: TransactionEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must set TxStartPoint (and the matching TxStopPoint) to reflect the billing model; a poor pairing (e.g. start on ParkingBayOccupancy, stop on EVConnected) can leave a transaction that never closes.

#E02 — Start Transaction - Cable Plugin First

In the most common public-charging flow the driver plugs in before authorizing. With TxStartPoint = EVConnected, the station first reports the connector as Occupied via a NotifyEvent, then opens the transaction with a TransactionEvent (Started, trigger CablePluggedIn) even though the driver is not yet known. Once the driver authorizes (locally or via the CSMS), the station sends a TransactionEvent (Updated, trigger Authorized) carrying the idToken, locks the connector if the cable is not captive, starts the energy offer, and reports the move to Charging with a further Updated event. The station keeps the cache entry updated from the response, and continues to send Updated events through the session.

Messages: TransactionEvent (CS → CSMS), NotifyEvent (CS → CSMS)

#E03 — Start Transaction - IdToken First

The mirror of E02: the driver authorizes first, then plugs in. With TxStartPoint = Authorized, a successful authorization opens the transaction with a TransactionEvent (Started, trigger Authorized) before any cable is connected. When the driver plugs in within the connection timeout, the station reports the connector Occupied via NotifyEvent, sends an Updated event (EVConnected/CablePluggedIn), locks the connector, starts the energy offer, and reports Charging. If the cable is not plugged in within the timeout, the station ends the transaction with a TransactionEvent (Ended, trigger EVConnectTimeout, stop reason Timeout). The CSMS must always answer with a TransactionEvent response regardless of any sanity-check outcome.

Messages: TransactionEvent (CS → CSMS), NotifyEvent (CS → CSMS)

#E04 — Transaction started while Charging Station is offline

When the station is offline but can authorize a driver locally (Local Authorization List or Authorization Cache), it starts the transaction immediately, locks the connector, and begins the energy offer. The corresponding TransactionEvent (Started) is stored in a local queue with the offline flag set true. Once connectivity is restored — which may be minutes or days later — the station resumes communication (typically a Heartbeat first) and replays the queued events to the CSMS, which acknowledges and the messages leave the queue. The transaction is not tied to any particular TxStartPoint.

Messages: TransactionEvent (CS → CSMS), Heartbeat (CS → CSMS)

#E05 — Start Transaction - Id not Accepted

Because a station may have authorized a token locally on stale data, the CSMS re-validates the idToken in every TransactionEvent that carries one. If the response's idTokenInfo.status is not Accepted (e.g. Blocked, Invalid, Expired, Unknown), the station suspends or stops the energy offer according to policy. With StopTxOnInvalidId false it keeps the transaction open but suspends energy (an Updated event with SuspendedEVSE), optionally allowing a small top-up bounded by MaxEnergyOnInvalidId. With StopTxOnInvalidId true it deauthorizes — emitting an Updated or Ended event with trigger Deauthorized depending on TxStopPoint. The cable typically remains locked even when energy is cut.

Messages: TransactionEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must set StopTxOnInvalidId and MaxEnergyOnInvalidId, deciding whether a token the CSMS rejects mid-start merely suspends energy (allowing a capped amount) or terminates the transaction.

#E06 — Stop Transaction options

The counterpart to E01: TxStopPoint determines when the station closes the transaction with a TransactionEvent (eventType Ended). Stop points mirror the start options — ParkingBayOccupancy (the EV leaves the bay, trigger EVDeparted), EVConnected (cable unplugged / EV communication lost, trigger EVCommunicationLost, stop reason EVDisconnected), Authorized (driver no longer authorized), and PowerPathClosed/EnergyTransfer. The chosen stop point must form a coherent pair with the start point so every started transaction can eventually end.

Messages: TransactionEvent (CS → CSMS), NotifyEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must set TxStopPoint consistently with TxStartPoint and the billing model; an ill-matched pair risks transactions that never stop.

#E07 — Transaction locally stopped by IdToken

A driver ends a session by presenting the same (or a group-validated) idToken a second time. With TxStopPoint = Authorized or PowerPathClosed, the station stops the energy transfer, unlocks the cable if it is not captive, and reports a TransactionEvent (Ended, trigger StopAuthorized, stop reason Local). With other stop points the station instead first sends an Updated event (trigger StopAuthorized) and ends the transaction only when the configured stop condition is later met. The CSMS cannot veto a stop — it can only acknowledge it.

Messages: TransactionEvent (CS → CSMS)

#E08 — Transaction stopped while Charging Station is offline

The offline analogue of E07. While offline with a transaction ongoing, the driver presents an idToken; if the station can validate it locally — the same token that started the session, or a matching groupId found in the Local Authorization List or Authorization Cache — it stops the energy offer, unlocks a non-captive cable, and queues a TransactionEvent (Ended, offline = true). When connectivity returns, the station replays the queued stop event (typically after a Heartbeat) and the CSMS acknowledges it.

Messages: TransactionEvent (CS → CSMS), Heartbeat (CS → CSMS)

#E09 — When cable disconnected on EV-side: Stop Transaction

When StopTxOnEVSideDisconnect is true and the driver unplugs the cable at the vehicle, the station detects the loss, suspends the energy offer, and ends the transaction with a TransactionEvent (Ended, trigger EVCommunicationLost, stop reason EVDisconnected). The station-side connector behaves per UnlockOnEVSideDisconnect: if false it stays locked until the driver returns and authorizes; if true it unlocks immediately. Once the cable is fully removed, the station reports the connector Available via NotifyEvent. Plugging the cable back in does not resume the (already-ended) transaction.

Messages: TransactionEvent (CS → CSMS), NotifyEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must choose StopTxOnEVSideDisconnect (stop vs. suspend on EV-side unplug, see E10) and UnlockOnEVSideDisconnect, balancing convenience against the risk of an unattended live or unlocked connector.

#E10 — When cable disconnected on EV-side: Suspend Transaction

When StopTxOnEVSideDisconnect is false, an EV-side unplug suspends the energy offer for safety but keeps the transaction open. If the driver plugs back in, charging resumes and the station reports a TransactionEvent (Updated, trigger CablePluggedIn). For a non-captive cable the driver must re-authorize to unlock and end the session (trigger StopAuthorized), after which removal triggers a NotifyEvent reporting the connector Available. For a captive cable, if it is not reconnected within a vendor-defined timeout the station ends the transaction (trigger EVCommunicationLost, stop reason EVDisconnected). Combining this with UnlockOnEVSideDisconnect = true is discouraged, as it can leave an authorized transaction with an unlocked connector.

Messages: TransactionEvent (CS → CSMS), NotifyEvent (CS → CSMS)

ESCALATE: VENDOR-DEFINED — The reconnection timeout for a captive cable before the suspended transaction is ended is not specified by OCPP and is left to the Charging Station implementer.

#E11 — Connection Loss During Transaction

A transaction continues normally even when the station loses its CSMS link mid-session. While offline the station queues all the TransactionEvent messages it would otherwise have sent, and replays them with the offline flag set once the connection is restored, then resumes normal communication. If memory runs low the station may drop intermediate Updated events — never the first or last — and may split bulky meter data across multiple Updated events sharing a timestamp; signed meter values are still captured when SampledDataSignReadings is true.

Messages: TransactionEvent (CS → CSMS)

#E12 — Inform CSMS of an Offline Occurred Transaction

This covers a transaction that both started and stopped while the station was offline. After reconnecting (and sending a Heartbeat), the station replays the full queued sequence for that transaction in order — Started, any Updated, and Ended — each with the offline flag true, and the CSMS acknowledges each so it can reconstruct and bill the entire session that happened during the outage.

Messages: TransactionEvent (CS → CSMS), Heartbeat (CS → CSMS)

This defines retry behavior when the CSMS, while online, rejects a transaction message or fails to answer within the message timeout (distinct from being fully offline). The station resends the same message, waiting before each retry for an interval equal to MessageAttemptIntervalTransactionEvent multiplied by the number of prior attempts, up to MessageAttemptsTransactionEvent total attempts. If the final attempt still fails, the station discards that message and proceeds to the next queued transaction message. For example, with three attempts and a 60-second base interval, the waits are 60s then 120s before the message is dropped.

Messages: TransactionEvent (CS → CSMS)

ESCALATE: POLICY-DEPENDENT — The operator must tune MessageAttemptsTransactionEvent and MessageAttemptIntervalTransactionEvent, trading delivery persistence against the risk of permanently losing transaction data after the attempt budget is exhausted.

#E14 — Check transaction status

The CSMS can ask whether a transaction is still running and whether the station still has undelivered messages for it, using GetTransactionStatus. With a transactionId the response reports ongoingIndicator (transaction still active) and messagesInQueue (pending messages for that transaction); without one, only messagesInQueue is returned for the queue as a whole. This is useful when the CSMS receives an Ended event but notices a gap in sequence numbers and wants to decide whether to wait or bill immediately. A response with both indicators false means either the transaction is finished with nothing pending, or the station no longer knows the transaction.

Messages: GetTransactionStatus (CSMS → CS)

#E15 — End of charging process

This aligns OCPP with the ISO 15118 end-of-charging flow (ISO 15118-1 H1). When the EV signals it is done — e.g. a SessionStopReq(Terminate) — and the charging session closes, the station reports the transaction to the CSMS. Depending on TxStopPoint, if it has not already sent a StopAuthorized trigger it emits either a TransactionEvent (Ended, trigger StopAuthorized, stop reason StoppedByEV) for stop points like Authorized/PowerPathClosed/EnergyTransfer, or an Updated event (trigger StopAuthorized) for others. Configured meter measurands are attached to the Ended event; under memory pressure intermediate values may be dropped but never the start and end readings.

Messages: TransactionEvent (CS → CSMS)

#E16 — Transactions with fixed cost, energy, SoC or time

New in OCPP 2.1: a driver or the CSMS can cap a transaction by cost, energy, state of charge, or time, and the limit may be changed mid-session more than once. A driver-set limit (e.g. an energy ceiling entered at the UI) is reported in transactionInfo.transactionLimit on the next TransactionEvent (trigger LimitChanged); a CSMS-set limit (e.g. a prepaid balance or direct-payment hold as maxCost) is delivered in a TransactionEvent response and echoed back by the station as confirmation. When a limit is reached the station suspends energy and reports it with trigger EnergyLimitReached or CostLimitReached and chargingState SuspendedEVSE; raising the limit resumes transfer. Note it is the energy transfer, not the transaction duration, that is limited — the transaction still ends per TxStopPoint. If the station cannot calculate cost locally it relies on cost updates from the CSMS (in the TransactionEvent response or a CostUpdated) to know when to stop. Supported limits are advertised in TxCtrlr.SupportedLimits, and if several limits are set the first one reached ends the transfer.

Messages: TransactionEvent (CS → CSMS), CostUpdated (CSMS → CS)

ESCALATE: POLICY-DEPENDENT — The operator/CSMS must decide which limit types to set and their values, and whether cost is calculated locally (precise cut-off) or driven by CSMS cost updates (which stop at or near the limit).

#E17 — Resuming transaction after forced reboot

New in OCPP 2.1: a transaction can survive an unexpected reboot — power loss, watchdog event, maintenance mode, or software fault. If TxResumptionTimeout is greater than zero and the interruption was no longer than that timeout, the station restores each affected transaction to its pre-reboot charging state on restart and reports a TransactionEvent (Updated, trigger TxResumed). If TxAllowEnergyTransferResumption is false, energy transfer is not automatically resumed (a previously Charging state returns as SuspendedEVSE), guarding against a different EV having been plugged in during the outage. If the interruption exceeded the timeout, the station ends the transaction with a TransactionEvent (Ended, trigger AbnormalCondition, stop reason PowerLoss or Reboot). Because TxProfile charging profiles need not persist, the CSMS may re-send any applicable profile with SetChargingProfile after resumption.

Messages: TransactionEvent (CS → CSMS), SetChargingProfile (CSMS → CS)

ESCALATE: POLICY-DEPENDENT — The operator must set TxResumptionTimeout and TxAllowEnergyTransferResumption, trading transaction continuity across outages against the safety risk of auto-resuming energy when the vehicle at the plug may have changed.

#F. Remote Control

#F01 — Remote Start Transaction - Cable Plugin First

When an EV driver plugs the cable first and the charging station has already started a transaction (triggerReason CablePluggedIn or EVConnectTimedOut), the CSMS can subsequently send a RequestStartTransaction to associate that session with a specific user identity. The charging station returns the already-running transactionId in the response so the CSMS can link the two. If AuthorizeRemoteStart is set to true, the charging station additionally performs an authorization check before enabling energy flow. Energy transfer begins and the charging station reports progress via TransactionEvent with triggerReason = RemoteStart.

Messages: RequestStartTransaction, TransactionEvent

ESCALATE: POLICY-DEPENDENT — The operator must decide whether AuthorizeRemoteStart is enabled, determining if a backend-initiated start still requires the charging station to perform a local authorization round-trip before energy flows.

#F02 — Remote Start Transaction - Remote Start First

The CSMS initiates a session before the EV driver connects by sending RequestStartTransaction with an idToken and optionally an evseId. The charging station responds Accepted and begins waiting for the cable to be plugged in; a new transaction is started immediately with triggerReason = RemoteStart. If the cable is not connected within the ConnectionTimeOut interval, the charging station ends the transaction with triggerReason = EVConnectTimeout. Once connected, energy transfer starts and subsequent state changes are reported as TransactionEvent updates.

Messages: RequestStartTransaction, TransactionEvent

ESCALATE: OPERATOR-CONFIG — The operator must configure ConnectionTimeOut to balance usability (giving drivers time to plug) against EVSE lock-up when a driver never arrives; the default value may not suit all deployment contexts.

#F03 — Remote Stop Transaction

The CSMS sends RequestStopTransaction carrying the transactionId it wishes to end. The charging station stops energy transfer, optionally unlocks the cable-retention lock, and emits a TransactionEvent with triggerReason = RemoteStop followed by an Ended event once the cable is unplugged. The charging station responds Accepted if the transaction exists and is active, or Rejected if the transactionId is unknown.

Messages: RequestStopTransaction, TransactionEvent

ESCALATE: OPERATOR-CONFIG — The operator must configure StopTxOnEVSideDisconnect and UnlockConnectorOnEVSideDisconnect to specify whether a remote stop automatically unlocks the connector; some deployments keep the connector locked until the driver physically requests release.

#F04 — Remote Stop ISO 15118 Charging from CSMS

This use case mirrors F03 but targets sessions conducted over ISO 15118-2 or ISO 15118-20. After receiving RequestStopTransaction, the charging station stops energy transfer and additionally sends the appropriate ISO 15118 control signal to the vehicle: EVSENotification = StopCharging for ISO 15118-2 sessions or a Terminate message for ISO 15118-20. The transaction is then closed in OCPP in the same way as a regular remote stop.

Messages: RequestStopTransaction, TransactionEvent

ESCALATE: VENDOR-DEFINED — The vendor must implement the correct ISO 15118 session-termination signal path; the OCPP spec delegates the EV-side signaling mechanism entirely to the charging station implementation.

#F05 — Remotely Unlock Connector

When an EV driver cannot unplug a cable because the cable-retention lock is stuck, the CSO can trigger a remote unlock by sending UnlockConnector with the target evseId and connectorId. The charging station attempts to release the lock and returns one of Unlocked, UnlockFailed, UnknownConnector, or OngoingAuthorizedTransaction. This message targets only the cable-retention lock, not an access-door lock; if the connector has no motorized lock the charging station should respond with a CALLERROR: NotSupported.

Messages: UnlockConnector

ESCALATE: OPERATOR-POLICY — The operator must define the procedure for notifying the driver and dispatching field service when UnlockFailed is returned, as the protocol provides no automatic escalation path beyond the single response status.

#F06 — Trigger Message

The CSMS can demand that a charging station send a specific CS-initiated message on demand by issuing TriggerMessage with a requestedMessage value and an optional evse scope. The charging station first replies with Accepted, Rejected, or NotImplemented, and then — if accepted — sends the requested message with current data (e.g. a TransactionEvent with triggerReason = Trigger, a MeterValues snapshot, or a StatusNotification). OCPP 2.1 adds CustomTrigger support, allowing the CSMS to request vendor-specific message types declared in the charging station's CustomizationCtrlr.CustomTriggers variable.

Messages: TriggerMessage

ESCALATE: VENDOR-DEFINED — Custom trigger identifiers are vendor-defined; the CSMS must know which custom trigger strings a given charging station model supports, which requires out-of-band coordination between vendor and operator.

#F07 — Remote start with fixed cost, energy, SoC or time

This use case (new in OCPP 2.1) lets the CSMS cap a remotely started session by delivering a transactionLimit in the first TransactionEventResponse after the session eventType = Started is received. The limit can specify one or more of maxCost, maxEnergy, maxTime, or maxSoC. The charging station echoes the limit back in the next TransactionEventRequest and enforces it by suspending energy delivery (SuspendedEVSE) once the threshold is reached. The initial RequestStartTransaction follows F01 or F02 flow normally.

Messages: RequestStartTransaction, TransactionEvent

ESCALATE: POLICY-DEPENDENT — The CSMS must determine which limit dimension(s) to apply and how to source the values (e.g. from a tariff engine, a driver preference, or a grid contract); the protocol does not prescribe how the limit is calculated or communicated to the driver before the session starts.

#G. Availability

#G01 — Report connector AvailabilityState

Whenever a connector's availability state changes — because a cable was plugged in, unplugged, or a ChangeAvailability command was processed — the charging station reports the new state to the CSMS. The preferred method in OCPP 2.1 is a NotifyEvent with component.name = "Connector", variable = "AvailabilityState", actualValue set to the new state string, and trigger = Delta; the older StatusNotification is an accepted alternative but is deprecated and will be removed in a future release. An Unavailable state set by a ChangeAvailability command persists across reboots. When a cable is plugged into one connector on a multi-connector EVSE, the charging station must not report a state change for the other connectors on that EVSE.

Messages: NotifyEvent, StatusNotification

ESCALATE: OPERATOR-CONFIG — The operator must configure the CSMS to handle both NotifyEvent (preferred) and StatusNotification (legacy) reports for connector status, since the spec allows charging stations to choose either path during the transition period.

#G02 — Heartbeat

A charging station sends a Heartbeat to the CSMS at regular intervals configured by HeartbeatInterval to confirm it is still online; the interval is set from the BootNotificationResponse after a successful registration. The HeartbeatResponse carries the CSMS's currentTime, which the charging station may use to synchronize its internal clock. Over WebSocket, the heartbeat is not needed to keep the connection alive, but if it is used for clock synchronization it should be sent at least once every 24 hours even when other messages are flowing continuously.

Messages: Heartbeat

ESCALATE: OPERATOR-CONFIG — The operator must decide the HeartbeatInterval value and whether clock synchronization via heartbeat is required; setting the interval too high wastes bandwidth, while too low a value may mask connectivity problems.

#G03 — Change Availability EVSE/Connector

The CSMS can set a specific EVSE or connector to Operative or Inoperative by sending ChangeAvailability with an evse object identifying the target and the desired operationalStatus. If a transaction is in progress on the targeted EVSE, the charging station responds Scheduled and applies the change after the transaction ends; otherwise it responds Accepted immediately. After the state change takes effect, the charging station reports the new status for each affected connector (and EVSE) via NotifyEvent or StatusNotification. EVSEs and connectors have independent states, and the set availability persists across reboots.

Messages: ChangeAvailability, NotifyEvent, StatusNotification

ESCALATE: OPERATOR-POLICY — The operator must define how the CSMS handles Scheduled responses — i.e., whether to track pending availability changes, set a timeout, or alert staff — as the protocol does not mandate any follow-up mechanism after the response is received.

#G04 — Change Availability Charging Station

This is a station-level variant of G03: omitting the evse field in ChangeAvailability instructs the charging station to change the availability of the entire unit. When set to Inoperative, all operative EVSEs and connectors (those not already Faulted) become Unavailable; when restored to Operative, the charging station reverts all EVSEs and connectors to their individual pre-change states. If any transaction is in progress, the response is Scheduled and the change is deferred. The availability state set this way persists across power loss or reboot.

Messages: ChangeAvailability, NotifyEvent, StatusNotification

ESCALATE: OPERATOR-POLICY — The operator must decide the maintenance workflow: whether to wait for in-flight transactions to conclude before sending the station-wide Inoperative command, and how long to wait before escalating to a forced stop.

#G05 — Lock Failure

After an EV driver is authorized and plugs in, if the charging station's cable-retention lock fails to engage, the station must not start energy transfer and must report the hardware fault. The charging station sends a NotifyEvent for the ConnectorPlugRetentionLock component with variable = Problem and value = True. The CSMS may optionally surface an alert to the driver (e.g. "cable cannot be locked") through external channels; the charging station itself may show a local notification. A lock failure can also be triggered when unlocking a connector (F05) fails.

Messages: NotifyEvent

ESCALATE: OPERATOR-POLICY — The operator must decide how a lock-failure event is handled operationally: whether to automatically set the connector Inoperative, dispatch a technician, or notify the driver through a separate channel, as OCPP defines only the fault-reporting step.

#H. Reservation

#H01 — Reservation

The CSMS reserves an EVSE for a specific EV driver by sending ReserveNow with an idToken, an expiryDateTime, and optionally an evseId or a connectorType. If evseId is omitted, the charging station reserves any available EVSE on the station; if evseId is provided, only that specific EVSE is reserved. On success the charging station responds Accepted and reports the connector status change to Reserved via NotifyEvent (or the legacy StatusNotification). Only available EVSEs can be reserved; the spec acknowledges that reserving a currently occupied EVSE is possible if the CSMS delays sending the message until the EVSE becomes free.

Messages: ReserveNow, NotifyEvent, StatusNotification

ESCALATE: POLICY-DEPENDENT — The operator must define the maximum reservation window, how to handle a reservation that outlasts the expiry without being used, and whether to charge a no-show fee — none of which are specified by the protocol.

#H02 — Cancel Reservation

The CSMS can withdraw an active reservation before its expiry time by sending CancelReservation with the reservationId originally assigned in H01. If the reservation is found and removed, the charging station responds Accepted and the EVSE returns to Available; if the reservationId is unknown, it responds Rejected. A connector state update (NotifyEvent or StatusNotification) is sent to reflect the availability change.

Messages: CancelReservation, NotifyEvent, StatusNotification

ESCALATE: OPERATOR-POLICY — The operator must decide whether a driver-requested cancellation is routed through the CSMS to the charging station or handled locally, and whether any cancellation penalty is applied at the CSMS layer.

#H03 — Use a reserved EVSE

When the driver whose idToken (or groupIdToken) matches the reservation presents their credential at the reserved EVSE, the charging station clears the reservation and begins the authorization and transaction flow as normal. The charging station sends ReservationStatusUpdate with reservationUpdateStatus = Removed to inform the CSMS that the reservation was consumed. If a different driver's token is presented, the charging station rejects it (or handles it according to the authorization result) and the reservation remains active.

Messages: ReservationStatusUpdate, TransactionEvent

ESCALATE: OPERATOR-POLICY — The operator must configure what happens when a third-party driver attempts to use a reserved EVSE: whether to reject silently, show an error, or allow charging if capacity permits; the spec does not prescribe behavior beyond keeping the reservation intact.

#H04 — Reservation Ended, not used

If the reservation expires before the reserved driver shows up, the charging station automatically releases the EVSE and informs the CSMS by sending ReservationStatusUpdate with reservationUpdateStatus = Expired. Similarly, if the reservation is cleared for any other reason without a transaction being started, the status NoTransaction is used. After the reservation ends, the connector reverts to Available and the CSMS is responsible for any downstream actions such as charging a no-show fee.

Messages: ReservationStatusUpdate, NotifyEvent, StatusNotification

ESCALATE: OPERATOR-POLICY — The operator must define the business logic that executes when a reservation expires unused: whether to notify the driver, levy a penalty, re-open the slot to walk-up users, or trigger a new reservation offer — all of which lie outside the OCPP protocol boundary.

#I. Tariff And Cost

#I01 — Show EV Driver-specific Tariff Information

Before a transaction starts, the EV Driver presents an identification token and the Charging Station authorizes it with the CSMS. When the CSMS recognizes the driver it can attach a human-readable, driver-specific tariff description to the authorization result, which the Charging Station then displays so the driver knows the price before committing to charge. This use case only covers showing a textual representation of the tariff; it does not require the Charging Station to support the structured TariffType used for local cost calculation. See Tariff And Cost deep-dive for how this fits the central- versus local-calculation split.

Messages: Authorize

ESCALATE: OPERATOR-POLICY — The wording, language(s), currency formatting and level of detail of the driver-facing tariff text, and whether the same message is shown to every token, are commercial/UX decisions the operator must define; the protocol only carries the free-text personal message.

#I02 — Show EV Driver Running Total Cost During Charging

While a transaction is in progress, the driver wants to see the accumulating cost. With central cost calculation the CSMS owns the running total and pushes periodic updates to the Charging Station via CostUpdated, or returns the running cost in the response to a transaction event the station already sends. The Charging Station then renders that figure on its display. The update frequency is a trade-off: more frequent updates give a smoother display but generate more traffic and mobile-data cost.

Messages: CostUpdated, TransactionEvent

ESCALATE: OPERATOR-POLICY — How often the CSMS recomputes and pushes the running total (the update interval) balances display freshness against messaging cost and is an operator deployment decision, not fixed by the protocol.

#I03 — Show EV Driver Final Total Cost After Charging

When the driver stops the transaction, the Charging Station reports the end event to the CSMS, which returns the final total cost in its response. The Charging Station displays that figure so the driver sees the final price before leaving. A free transaction is signalled by a total cost of exactly 0.00 — omitting the cost does not mean free. If the station was offline at stop time, or the stop model requires the driver to physically leave (parking-bay occupancy) before the transaction ends, there may be no display opportunity; see I05 — Show Fallback Total Cost Message.

Messages: TransactionEvent

ESCALATE: OPERATOR-POLICY — Whether and how the final cost is surfaced (on-station display, app, email receipt), and the settlement/refund handling for the figure shown, are operator commercial decisions; OCPP only delivers the computed total.

#I04 — Show Fallback Tariff Information

When the Charging Station cannot obtain a driver-specific tariff before charging — for example it is offline, or the CSMS returns no tariff for the token — it falls back to a generic message configured locally in TariffFallbackMessage. This gives the driver at least some price indication instead of nothing. The fallback text can be set or updated by the CSMS through that configuration variable. This is the degraded-mode counterpart to I01 — Show EV Driver-specific Tariff Information.

Messages: No dedicated message.

ESCALATE: OPERATOR-POLICY — The content of the fallback tariff message (and whether a generic price is even advertised when the real tariff is unknown) is a commercial/regulatory decision; advertising a price the operator cannot guarantee may carry consumer-protection implications.

#I05 — Show Fallback Total Cost Message

When a transaction is stopped while the Charging Station is offline, the station cannot retrieve the final total cost from the CSMS. Instead of leaving the driver with no information it shows a pre-configured fallback message from TotalCostFallbackMessage. This is the offline counterpart to I03 — Show EV Driver Final Total Cost After Charging. The fallback text can be configured by the CSMS via that configuration variable.

Messages: No dedicated message.

ESCALATE: OPERATOR-POLICY — The wording of the offline total-cost fallback message, and how the driver later obtains the actual billed amount once the station reconnects, are operator decisions outside the protocol.

#I06 — Update Tariff Information During Transaction

Some tariffs vary during a session — for example DC fast charging priced against a moving day-ahead energy price, often quoted as a range with a current value. As the Charging Station sends its periodic transaction-event updates, the CSMS checks whether newer tariff text is available and returns it in the response (in the personal-message fields, optionally in several languages), which the station then displays. Note that local regulation or contract terms may forbid changing the advertised tariff mid-session, in which case no update should be sent.

Messages: TransactionEvent

ESCALATE: REGULATORY — Whether the tariff communicated at session start may change during the transaction, and under what disclosure conditions, is governed by local consumer-protection law and the operator's contract terms, not by OCPP.

#I07 — Local Cost Calculation - Set Default Tariff

New in OCPP 2.1: the CSMS installs a structured tariff on the Charging Station so the station can calculate cost locally. SetDefaultTariff with evseId = 0 installs the tariff on every EVSE; a non-zero evseId targets one EVSE and overrides the station-wide default there. Each tariff carries a unique tariffId, so updating a default means installing a new tariff (optionally with a future validFrom so it activates at a scheduled time and replaces the prior default). Only one tariff structure fits per message because tariffs can be large. See the Tariff And Cost deep-dive for the tariff structure and the validFrom activation rules.

Messages: SetDefaultTariff

ESCALATE: OPERATOR-POLICY — The actual prices, currency, tax rates, time-of-day conditions and fixed/idle fees in the default tariff are commercial and tax-jurisdiction values the operator must supply; the protocol only transports the structure.

#I08 — Local Cost Calculation - Receive Driver Tariff

New in OCPP 2.1: instead of (or on top of) the default tariff, the CSMS can return a driver-specific tariff inside the authorization result, which the Charging Station then uses for local cost calculation of that driver's transaction. The driver-specific tariff is "in use" from when it is received until the transaction for that token ends. If the driver does not accept the tariff the station deauthorizes; if the station receives a tariff it cannot process, the configured HandleFailedTariff strategy decides whether to refuse charging, fall back to the default tariff, or defer to central calculation by the CSMS. A driver-specific tariff may also arrive via I11 — Local Cost Calculation - Change transaction tariff.

Messages: Authorize, TransactionEvent

ESCALATE: OPERATOR-POLICY — The HandleFailedTariff behaviour (deauthorize, use default, or central cost) and whether implicit tariff acceptance (e.g. plugging in the cable) is treated as consent are operator/regulatory choices the deployment must set.

#I09 — Local Cost Calculation - Get Tariffs

New in OCPP 2.1: the CSMS queries which tariffs are currently present on a Charging Station. GetTariffs with evseId = 0 returns the tariffs across all EVSEs; a non-zero evseId scopes the result to one EVSE. The response lists tariff assignments per EVSE, distinguishing default tariffs (installed on every EVSE) from driver-specific tariffs (tied to a token, and reported with the EVSE where a transaction is active). If nothing matches, the station replies with status NoTariff.

Messages: GetTariffs

#I10 — Local Cost Calculation - Clear Tariffs

New in OCPP 2.1: the CSMS removes one or more default tariffs from a Charging Station. ClearTariffs can target specific tariffIds, a specific evseId, both, or neither (clear all). Driver-specific tariffs are not cleared by this message — they are removed automatically when no longer in use. A default tariff that is currently in use by an active transaction is reported as cleared but continues to be applied until that transaction ends, so running sessions are never disrupted.

Messages: ClearTariffs

#I11 — Local Cost Calculation - Change transaction tariff

New in OCPP 2.1: the CSMS swaps the tariff associated with an ongoing transaction, for example to handle an unexpected price change. ChangeTransactionTariff targets a transactionId (the change is bound to the transaction, not the driver, since the same driver may have other sessions that should not change). The station validates the new tariff and may reject with reasons such as TooManyElements, ConditionNotSupported, NoCurrencyChange (currency cannot switch mid-transaction) or TxNotFound. On acceptance the new tariff applies from that moment forward with no retroactive recalculation, and the station emits a transaction event marking the change.

Messages: ChangeTransactionTariff, TransactionEvent

ESCALATE: REGULATORY — Whether a tariff may be changed during an active transaction at all, and whether explicit customer agreement is required first, depends on local legislation and contract terms outside OCPP.

#I12 — Local Cost Calculation - Cost Details of Transaction

New in OCPP 2.1: when local cost calculation is active, the Charging Station produces a detailed cost breakdown and returns it to the CSMS so the CSMS can generate invoices or Charge Detail Records. During the session the station may send running cost updates (without per-period detail, to limit data); when the transaction ends it includes a full breakdown in the end event — a list of charging periods (one per pricing change), per-dimension totals for fixed fee, energy, charging time, idle time and reservation, and the overall total with tax handling (stacked tax rates, optional min/max cost capping). If the station cannot compute the cost it flags the failure rather than reporting a wrong figure. See the Tariff And Cost deep-dive for the CostDetails structure and the tax-stacking and min/max rules.

Messages: TransactionEvent

ESCALATE: REGULATORY — Tax-rate stacking (e.g. energy tax then VAT), invoice/CDR formatting and the legal validity of the locally calculated breakdown for billing are jurisdiction-specific decisions the operator and its tax advisor must make; OCPP only carries the numbers.

#J. Meter Values

The Charging Station samples its energy meter or other sensors and sends those readings to the CSMS outside of any transaction, using the dedicated MeterValues message. Clock-aligned readings (taken at fixed wall-clock intervals such as every quarter hour, configured via AlignedDataCtrlr) and standalone diagnostic samples both travel this way. Each reading carries a timestamp and one or more sampled values, optionally tagged with measurand, context, location and phase; signed meter values can be included for fiscally certified meters. When an EVSE is in a transaction its clock-aligned values are sent inside transaction events instead, and AlignedDataSendDuringIdle can restrict aligned values to idle periods only.

Messages: MeterValues

ESCALATE: VENDOR-CONFIG — Which measurands are sampled, at what interval, at which locations/phases, and whether upstream (potentially privacy-sensitive) measurands are reported are deployment configuration choices; upstream measurands may require an explicit agreement due to data-protection and liability implications.

During an ongoing transaction the Charging Station samples metering data and offloads it to the CSMS inside transaction-event updates rather than standalone MeterValues messages. The measurands and sampling interval are configured through SampledDataCtrlr (TxUpdatedMeasurands / TxUpdatedInterval). All meter values reported must relate to the EVSE on which the transaction runs, and register values must increase monotonically and be read directly from the meter (not re-based to zero per transaction) so the CSMS can audit for missing energy between sessions. If the station is offline it queues these messages; if it is offline and low on memory it may drop intermediate updates first, never breaking the queue order. Signed meter values can be attached when supported.

Messages: TransactionEvent

ESCALATE: VENDOR-CONFIG — The set of transaction measurands and the sampling interval, plus the behaviour when memory is constrained, are deployment configuration decisions; the fiscal-meter register values themselves may carry billing/legal-metrology obligations.

#J03 — Charging Loop with metering information exchange

This use case maps the ISO 15118 metering loop onto OCPP. During AC or DC charging the EV requests metering status from the Charging Station, which returns fiscal-meter readings (with a signed meter reading where required), and the EV acknowledges receipt with a MeteringReceipt message. The Charging Station does not forward that ISO 15118 receipt to the CSMS directly; instead it reports the signed meter values to the CSMS as ordinary transaction-related meter values exactly as in J02 — Sending transaction related Meter Values. A station may, as an implementation choice, require an EV MeteringReceipt to acknowledge each fiscal reading before it is forwarded.

Messages: TransactionEvent

ESCALATE: VENDOR-CONFIG — Whether the Charging Station mandates an ISO 15118 MeteringReceipt acknowledgement from the EV before forwarding each fiscal meter value is a vendor/operator implementation decision, not fixed by OCPP.

#K. Smart Charging

#K01 — SetChargingProfile

The base smart-charging operation: the CSMS sends a charging profile to an EVSE (or to EVSE 0 for the whole station) to cap the power or current an EV may draw over a period of time, staying within whatever limits an external system imposes. A profile carries a purpose (TxProfile, TxDefaultProfile, ChargingStationMaxProfile, ChargingStationExternalConstraints, PriorityCharging, LocalGeneration), a stack level and a validity window; the station re-evaluates its active profiles whenever a new one is set. A TxProfile must reference a transactionId and is only applied if that transaction is known; the CSMS must not reuse the same stackLevel/purpose/evseId combination across overlapping profiles, and it must never set ChargingStationExternalConstraints itself (that purpose is reserved for externally imposed limits). See the OCPP 2.0.1 Smart Charging deep-dive for profile-purpose stacking and composite-schedule fundamentals.

Messages: SetChargingProfile

#K02 — Central Smart Charging

The CSMS holds the load-management intelligence centrally. After authorization the EVSE first applies whatever default profile it already holds (limiting the Control Pilot signal so the EV cannot draw full power before the CSMS reacts), and once the transaction starts the CSMS may respond to the transaction event by pushing a per-transaction TxProfile that overrules the TxDefaultProfile for the life of that session and is deleted when it ends. The station continuously adapts current/power to the merged active profiles. It is recommended to omit the schedule duration so the TxProfile lasts the whole transaction; if it expires early the station falls back to the lowest limit of the active TxDefaultProfile and ChargingStationMaxProfile, then to the local hardware limit. The CSMS should check the offline flag on a transaction event before sending a profile, since the event may have been cached.

Messages: SetChargingProfile, TransactionEvent

ESCALATE: VENDOR-CONFIG — How the CSMS calculates per-transaction constraints (the central load-balancing algorithm) is not specified by OCPP; it is an operator/vendor backend decision.

#K03 — Local Smart Charging

An illustrative (non-prescriptive) example of load-balancing performed by a Local Controller rather than the CSMS. The Local Controller is given a total cluster limit — via a ChargingStationMaxProfile from the CSMS or a ChargingStationExternalConstraints profile from an EMS — and divides that budget across active transactions. Charging stations carry a low TxDefaultProfile (e.g. 6 A) so a vehicle cannot pull full power before the controller intervenes; when a transaction starts or stops, the Local Controller re-issues TxProfiles to the remaining sessions to redistribute the available current. The Local Controller sits in the OCPP path between stations and CSMS, registering transaction IDs as it forwards transaction events. See the OCPP 2.0.1 Smart Charging deep-dive for the Local Controller topology.

Messages: SetChargingProfile, TransactionEvent

ESCALATE: VENDOR-CONFIG — The local load-balancing strategy (how the cluster budget is split, whether departure time or state-of-charge is considered) is an implementation choice; OCPP only carries the resulting profiles.

#K04 — Internal Load Balancing

Here the Charging Station itself balances current/power between its own EVSEs, rather than relying on the CSMS or a Local Controller. The station is configured with a fixed ceiling (typically the grid-connection limit) — expressed as a ChargingStationMaxProfile, which may only be set at EVSE 0 (the whole station) — and controls each EVSE's schedule so the combined draw stays within it. The optional minChargingRate field tells the station that charging below a certain rate is inefficient, letting it choose a smarter balancing strategy. New in 2.1: when a LocalGeneration profile is active, the combined energy flow may go up to ChargingStationMaxProfile + LocalGeneration (see K27).

Messages: SetChargingProfile

ESCALATE: VENDOR-CONFIG — The internal per-EVSE power-distribution algorithm is left to the Charging Station vendor; OCPP only sets the overall ceiling.

#K05 — Remote Start Transaction with Charging Profile

The CSMS embeds a charging profile directly in the remote-start request so the transaction is governed by the right schedule from the very first moment — important because, for example, the choice between three-phase and single-phase charging cannot always be changed once charging has begun, and because the station may go offline right after receiving the request. The included profile must have purpose TxProfile and cannot carry a transactionId (none exists yet); the station uses it when computing its composite schedule. A station that supports smart charging but receives an invalid profile rejects the start with InvalidProfile or InvalidSchedule; a station without smart-charging support simply ignores the profile.

Messages: RequestStartTransaction, TransactionEvent

#K06 — Offline Behavior Smart Charging During Transaction

Defines what a station does with smart charging when it loses CSMS connectivity mid-transaction. If it had already received a TxProfile for the active transaction, it keeps applying that profile until the transaction ends or the profile expires, whichever comes first, operating stand-alone with no need for the backend. If it holds no charging profiles at all when it goes offline, it runs the transaction as though no constraints apply. No dedicated message is exchanged while offline — this use case is about local fallback behaviour.

Messages: No dedicated message.

#K07 — Offline Behavior Smart Charging at Start of Transaction

Covers a transaction that both starts and runs while the station is offline. By installing a TxDefaultProfile ahead of time, the CSMS guarantees that any transaction begun during a connectivity outage is governed by a sensible schedule. The station authorizes the driver locally (Local Authorization List, Authorization Cache, or OfflineTxForUnknownIdEnabled), starts the transaction as usual, and continuously adapts current/power to the already-installed default profile. See K01 and the OCPP 2.0.1 Smart Charging deep-dive for how profile purposes combine.

Messages: No dedicated message.

#K08 — Get Composite Schedule

The CSMS asks the station to report its composite schedule — the single effective schedule that results from merging all active charging profiles of the different purposes plus any local limits, taking the most restrictive value in each time interval. The report shows the power or current the station expects to draw from the grid for the requested EVSE over the requested duration; requesting EVSE 0 yields the total grid-connection forecast. The result is only indicative for that instant, since local balancing or an EVSE becoming free can change it later. New in 2.1: when no transaction is active the station computes the schedule as if a TxDefaultProfile-driven transaction were running (with randomizedDelay = 0); V2X-aware merging caps setpoint between dischargeLimit and limit, reports per-phase limit_L2/limit_L3 values, and adds LocalGeneration capacity on top of the merged limit. See the V2X bidirectional deep-dive for setpoint/dischargeLimit sign conventions.

Messages: GetCompositeSchedule

#K09 — Get Charging Profiles

The CSMS retrieves the charging profiles currently installed in a station — all of them or a filtered subset — for automatic control logic or operator debugging. The request filters either by a list of chargingProfileIds, or by some combination of stackLevel, chargingLimitSource and chargingProfilePurpose, optionally scoped to a specific evseId (EVSE 0 returns only the station-level profiles such as ChargingStationMaxProfile and ChargingStationExternalConstraints). The station acknowledges with Accepted or NoProfiles if nothing matches, then streams the matching profiles back in one or more report messages, each carrying the original requestId and a tbc (to-be-continued) flag set on every report except the last.

Messages: GetChargingProfiles, ReportChargingProfiles

#K10 — Clear Charging Profile

The CSMS removes some or all previously installed charging profiles. The request can target a specific profile id, or filter by evseId, chargingProfilePurpose and stackLevel; the station clears every profile matching the supplied criteria and reports whether anything matched. If no installed profile matches, the station responds Unknown rather than treating it as an error.

Messages: ClearChargingProfile

#K11 — Set / Update External Charging Limit With Ongoing Transaction

An External Control System — a DSO, smart meter, or home energy-management system — imposes a limit or schedule on the station over a non-OCPP interface (IEC 61850, OpenADR, or any protocol the station supports), and the station honours it for ongoing transactions while keeping the CSMS informed. The station never charges faster than the external limit (unless ExternalConstraintsProfileDisallowed is set), represents the limit internally as a ChargingStationExternalConstraints profile, and when the limit changes by more than LimitChangeSignificance it sends a NotifyChargingLimit (with chargingLimitSource never set to CSO, optionally including the schedule when EnableNotifyChargingLimitWithSchedules is true). If the actual charging rate changes significantly it also emits a transaction event with triggerReason = ChargingRateChanged. New in 2.1, the station may represent the external limit as an Absolute, Relative, or Dynamic profile (operationMode = ExternalLimits).

Messages: NotifyChargingLimit, TransactionEvent

ESCALATE: VENDOR-CONFIG — The interface and protocol between the External Control System and the station, and whether limits are modelled as Absolute/Relative/Dynamic profiles, are deployment decisions outside OCPP.

#K12 — Set / Update External Charging Limit Without Ongoing Transaction

The same external-limit mechanism as K11, but applied when no transaction is active — the limit constrains the grid connection and any future transactions rather than an in-progress session. The total load of all EVSEs must stay within the received limit, the station represents it as a ChargingStationExternalConstraints profile (it is recommended to use negative profile IDs to avoid clashing with CSMS-assigned IDs), and it notifies the CSMS via NotifyChargingLimit when the limit changes by more than LimitChangeSignificance, again never using chargingLimitSource = CSO. Because no transaction is running, no transaction event is involved.

Messages: NotifyChargingLimit

ESCALATE: VENDOR-CONFIG — The non-OCPP interface to the external system and the profile representation are deployment decisions outside OCPP.

#K13 — Reset / Release External Charging Limit

The mirror of K11/K12: the External Control System lifts a previously imposed limit. The station stops constraining charging based on that limit, and if a transaction is ongoing it recalculates the schedule and ramps the charging rate back up. It tells the CSMS the limit is gone by sending ClearedChargingLimit (carrying the chargingLimitSource), and if the resulting rate change on an active transaction exceeds LimitChangeSignificance it also emits a transaction event with triggerReason = ChargingRateChanged.

Messages: ClearedChargingLimit, TransactionEvent

#K14 — External Charging Limit with Local Controller

The external-limit pattern applied to a cluster managed by a Local Controller instead of a single station. When the External Control System sets a grid limit, the Local Controller notifies the CSMS with NotifyChargingLimit, recalculates schedules for the whole cluster, and pushes a SetChargingProfile to every station whose profile changed. When the external limit is released, it sends ClearedChargingLimit and clears the affected profiles with ClearChargingProfile. Requires ExternalControlSignalsEnabled = true.

Messages: NotifyChargingLimit, SetChargingProfile, ClearedChargingLimit, ClearChargingProfile

ESCALATE: VENDOR-CONFIG — The Local Controller's cluster-recalculation algorithm and its non-OCPP link to the External Control System are implementation decisions outside OCPP.

#K15 — ISO 15118-2 Charging with load leveling

Maps ISO 15118-2 high-level-communication charging (AC or DC) onto OCPP smart charging. When the EV sends its ChargeParameterDiscoveryReq, the station relays the EV's energy needs to the CSMS via NotifyEVChargingNeeds; the CSMS computes a schedule and returns it as a SetChargingProfile TxProfile, which the station folds into the ISO 15118 ChargeParameterDiscoveryRes (SAScheduleList) it sends back to the EV. Because that ISO message has a 60-second timeout, the CSMS must respond promptly — if it does not, or replies Processing, the station returns a schedule matching the EVSE's own capability and a late profile then triggers a renegotiation per K16. The TxStartPoint must fire before ChargeParameterDiscoveryReq so a transaction exists to attach the TxProfile to. Optionally the station forwards the EV's own calculated schedule with NotifyEVChargingSchedule. New in 2.1: signed SalesTariffs are supported via the signatureValue field.

Messages: NotifyEVChargingNeeds, SetChargingProfile, NotifyEVChargingSchedule, TransactionEvent

#K16 — Renegotiation initiated by CSMS

During an ISO 15118 session the CSMS changes the charging schedule by sending a new SetChargingProfile. The station cannot push this to the EV unilaterally; instead, on the EV's next CurrentDemandReq (DC) or ChargingStatusReq (AC) it signals evseNotification = ReNegotiation, the EV confirms with a PowerDeliveryReq (chargeProgress = ReNegotiate), and a fresh ChargeParameterDiscovery exchange then delivers the new SAScheduleList. The EV–station message detail is informative only; OCPP mandates only the profile push. Because every limit change in a dynamic schedule would force a renegotiation, the CSMS should avoid frequently updated Dynamic profiles for ISO 15118-2 sessions.

Messages: SetChargingProfile

#K17 — Renegotiation initiated by EV

The EV triggers the new schedule. When it sends a ChargeParameterDiscoveryReq carrying updated charging-needs parameters, the station forwards them to the CSMS via NotifyEVChargingNeeds; the CSMS computes a schedule that tries to honour the EV's needs while respecting other constraints and returns it as a SetChargingProfile. The station relays the new schedule to the EV in a ChargeParameterDiscoveryRes, the EV confirms with PowerDeliveryReq (chargeProgress = Start), and the station resumes power delivery if it had been suspended for the renegotiation. If the EV supplies its own charging profile, the station reports it back with NotifyEVChargingSchedule.

Messages: NotifyEVChargingNeeds, SetChargingProfile, NotifyEVChargingSchedule

#K18 — ISO 15118-20 Scheduled Control Mode

New in OCPP 2.1: ISO 15118-20 scheduled-control charging. After the EV sends its energy needs and departure time in a ScheduleExchangeReq, the station relays them to the CSMS via NotifyEVChargingNeeds with controlMode = ScheduledControl. The CSMS replies with a SetChargingProfile carrying up to three alternative charging schedules plus optional price information; the station offers these to the EV in its ScheduleExchangeRes, and the EV picks one and returns its own calculated schedule, which the station forwards with NotifyEVChargingSchedule. See the OCPP 2.1 Smart Charging deltas deep-dive for ISO 15118-20 control-mode details.

Messages: NotifyEVChargingNeeds, SetChargingProfile, NotifyEVChargingSchedule

#K19 — ISO 15118-20 Dynamic Control Mode

New in OCPP 2.1: ISO 15118-20 dynamic-control charging, where the operator (not the EV) drives the schedule in real time. The station relays the EV's ScheduleExchangeReq to the CSMS via NotifyEVChargingNeeds with controlMode = DynamicControl; the CSMS returns a single charging schedule plus optional price information in a SetChargingProfile. The station passes only the pricing schedule (not the charging schedule) to the EV in its ScheduleExchangeRes; the EV then sends its fastest-possible EVPowerProfile in a PowerDeliveryReq, which the station ignores, instead applying the CSMS schedule and reporting it back with NotifyEVChargingSchedule. See the OCPP 2.1 Smart Charging deltas deep-dive for dynamic-mode behaviour.

Messages: NotifyEVChargingNeeds, SetChargingProfile, NotifyEVChargingSchedule

#K20 — ISO 15118-20 Adjusting charging schedule when energy needs change

New in OCPP 2.1: handles a mid-session change in the EV's departure time or target energy during an ISO 15118-20 session, regardless of which actor noticed the change. Whether the new DepartureTime/EVTargetEnergyRequest arrives via the EV (in ScheduleExchangeReq for scheduled control, or ChargeLoopReq for dynamic control) or is set by the station itself, the station reports the updated needs to the CSMS with NotifyEVChargingNeeds. The CSMS recomputes and pushes a new schedule via SetChargingProfile, which the station applies — in scheduled mode it returns the schedule to the EV and forwards the EV's projected EVPowerProfile back with NotifyEVChargingSchedule; in dynamic mode it steers charging directly through the ChargeLoopRes.

Messages: NotifyEVChargingNeeds, SetChargingProfile, NotifyEVChargingSchedule

#K21 — Requesting priority charging remotely

New in OCPP 2.1: a driver requests immediate, maximum-power charging through the CSMS (for example via a smartphone app), overriding any V2X discharging or deferred schedule. The CSMS sends UsePriorityCharging with activate = true for the transaction; if the station holds a PriorityCharging profile it accepts, stops applying the TxDefaultProfile/TxProfile to that transaction, switches to the priority profile, and confirms with NotifyPriorityCharging (activated = true). If it has no such profile it responds NoProfile; if it cannot activate for another reason (e.g. unknown transaction) it responds Rejected. The priority profile stays in effect until the session ends or the CSMS deactivates it; the achieved power may still be below station maximum if other limits (e.g. load balancing) apply. Priority charging is not limited to V2X transactions. See the V2X bidirectional deep-dive for how priority charging suppresses discharging.

Messages: UsePriorityCharging, NotifyPriorityCharging

#K22 — Requesting priority charging locally

New in OCPP 2.1: the same priority-charging switch as K21, but triggered at the station itself (a button or display) rather than through the CSMS. The station stops applying the TxDefaultProfile/TxProfile to the transaction, switches to its PriorityCharging profile, and informs the CSMS with NotifyPriorityCharging (activated = true). If the station has no PriorityCharging profile it cannot switch. If it is offline when the user activates, it applies the priority profile immediately and queues the NotifyPriorityCharging message for when it reconnects. The profile remains active until the session ends or priority charging is cancelled.

Messages: NotifyPriorityCharging

#K23 — Smart Charging with EMS connected to Charging Stations

New in OCPP 2.1: a worked example of K11/K12 where the External Control System is a building Energy Management System wired directly to each station. The EMS measures other site loads and local generation, computes the power available for charging so the grid connection is not overloaded, and sets a limit (or schedule) on each station over a non-OCPP link. Each station represents this internally as a ChargingStationExternalConstraints profile and, when the limit shifts by more than LimitChangeSignificance, notifies the CSMS with NotifyChargingLimit (chargingLimitSource = EMS); an ongoing transaction also gets a transaction event with triggerReason = ChargingRateChanged. Requires ExternalControlSignalsEnabled = true. The requirements are fully covered by K11 and K12.

Messages: NotifyChargingLimit, TransactionEvent

ESCALATE: VENDOR-CONFIG — The EMS-to-station interface and the site load-management algorithm are deployment decisions outside OCPP.

#K24 — Smart Charging with EMS connected to Local Controller

New in OCPP 2.1: the K14 pattern where the External Control System is a building EMS wired to a Local Controller that manages a cluster of stations. The EMS regularly updates a current/power limit for the whole cluster to protect the grid connection; the Local Controller notifies the CSMS, recalculates per-station profiles, and pushes them down. The message flow and requirements are those of K14.

Messages: NotifyChargingLimit, SetChargingProfile, ClearedChargingLimit, ClearChargingProfile

ESCALATE: VENDOR-CONFIG — The EMS-to-Local-Controller interface and the cluster scheduling algorithm are deployment decisions outside OCPP.

#K25 — Smart Charging with EMS acting as a Local Controller

New in OCPP 2.1: the EMS and Local Controller are combined into one component, so all OCPP traffic passes through it. This lets the EMS-part see the full transaction state — schedules imposed by the CSMS, EV state-of-charge, planned departure time — and therefore do more advanced scheduling than an external EMS could. It calculates a power profile per station and sends each as a ChargingStationMaxProfile (in addition to any CSMS profiles flowing through it), keeping the grid connection within limits.

Messages: SetChargingProfile

ESCALATE: VENDOR-CONFIG — The combined EMS/Local-Controller scheduling logic and its site-measurement inputs are implementation decisions outside OCPP.

#K26 — Smart Charging with Hybrid Local & Cloud EMS

New in OCPP 2.1: a variant of K25 where the EMS is split between a cloud instance and a local on-site instance. Two topologies are possible: the cloud part handles scheduling and Local Controller functionality while the local part measures site loads and acts as a fail-safe against grid overload; or the cloud part handles only scheduling while the local part is the Local Controller plus fail-safe. Either way the local component provides the overload protection that a purely cloud-based EMS could not guarantee during connectivity loss. Profiles reach the stations as in K25 (ChargingStationMaxProfile via SetChargingProfile).

Messages: SetChargingProfile

ESCALATE: VENDOR-CONFIG — Which functions run in the cloud vs. on-site (the split topology), the inter-component protocol, and the fail-safe logic are deployment/vendor decisions outside OCPP.

#K27 — Smart Charging with EMS and LocalGeneration

New in OCPP 2.1: lets locally generated power (e.g. solar) that the CSMS does not know about be added on top of the normal charging limit. The station represents the generation forecast internally as a LocalGeneration charging profile; the effective ceiling becomes the merged limit plus the local-generation capacity (so, for example, a 5 kW TxDefaultProfile plus 2 kW of solar allows 7 kW). When the available generation changes by more than LimitChangeSignificance, the station notifies the CSMS with NotifyChargingLimit, flagging the source as local generation. See K04 for how LocalGeneration raises the ChargingStationMaxProfile ceiling.

Messages: NotifyChargingLimit

ESCALATE: VENDOR-CONFIG — How the station obtains and forecasts the local-generation schedule (the EMS interface) is a deployment decision outside OCPP.

#K28 — Dynamic charging profiles from CSMS

New in OCPP 2.1: a Dynamic charging profile has a single schedule period whose limit/setpoint can be updated repeatedly without resending the whole profile. Two update modes exist. Push: the CSMS first installs the dynamic profile with SetChargingProfile (no dynUpdateInterval), then sends new values with UpdateDynamicSchedule whenever it wants; the station applies each value and stamps dynUpdateTime. Pull: the CSMS installs the profile with a dynUpdateInterval (e.g. 60 s), and the station periodically requests fresh values with PullDynamicScheduleUpdate, the CSMS returning them in the response. In both modes, if a duration is set and no update arrives before it elapses the schedule ends and the station falls back to the next valid profile; with no duration the schedule lasts until cleared or replaced. See the OCPP 2.1 Smart Charging deltas deep-dive for dynamic-profile mechanics.

Messages: SetChargingProfile, UpdateDynamicSchedule, PullDynamicScheduleUpdate

#K29 — Dynamic charging profiles from external system

New in OCPP 2.1: a Dynamic profile whose limit/setpoint is updated not by the CSMS but by an external system, signalled with operationMode = ExternalLimits or ExternalSetpoint. In the first scenario the station itself originates the dynamic profile as a ChargingStationExternalConstraints profile fed by the external system, applies each new value as it arrives, and notifies the CSMS via NotifyChargingLimit (as in K11) when it shifts by more than LimitChangeSignificance. In the second, the CSMS pre-authorizes external control by sending a TxProfile/TxDefaultProfile whose period has operationMode = ExternalLimits/ExternalSetpoint, telling the station an external system will supply the values; this is the path used when ExternalConstraintsProfileDisallowed is true and the station is not permitted to create its own ChargingStationExternalConstraints profile. As with K28, an unrefreshed schedule expires after its duration and falls back to the next valid profile.

Messages: SetChargingProfile, NotifyChargingLimit

ESCALATE: VENDOR-CONFIG — Whether the station or the CSMS owns the externally driven profile (governed by ExternalConstraintsProfileDisallowed) and the external-system interface are deployment/policy decisions.

#L. Firmware Management

#L01 — Secure Firmware Update

The CSMS schedules a signed firmware upgrade by sending an UpdateFirmwareRequest that carries the download URI, a scheduled retrieval time, the manufacturer signing certificate, and a digital signature. The charging station waits until the scheduled time, downloads the image, verifies the certificate chain against the installed manufacturer root, and then validates the firmware signature before installing. Each phase is reported back through FirmwareStatusNotification: Downloading → Downloaded → SignatureVerified → Installing → Installed. If certificate validation fails the station reports InvalidCertificate and also emits a SecurityEventNotification; a signature mismatch yields InvalidSignature with the same security event, and the upgrade is aborted in both cases.

Messages: UpdateFirmwareRequest, FirmwareStatusNotification

#L02 — Non-Secure Firmware Update

The CSMS schedules a firmware upgrade without requiring a manufacturer certificate or digital signature. The UpdateFirmwareRequest carries only the download URI and a scheduled retrieval time; the charging station downloads and installs the image without any cryptographic verification step. Progress is reported through FirmwareStatusNotification with states Downloading → Downloaded → Installing → Installed (the SignatureVerified state does not appear because no signature check is performed). This variant is intended for deployments that rely on transport-layer security alone rather than end-to-end firmware signing.

Messages: UpdateFirmwareRequest, FirmwareStatusNotification

ESCALATE: SECURITY-POLICY — Choosing between secure (L01) and non-secure (L02) firmware update is a CSO security-policy decision; operators must decide which update path is permitted in their deployment.

#L03 — Publish Firmware file on Local Controller

When a fleet of charging stations shares a Local Controller on a common LAN, the CSMS can reduce WAN traffic by pre-staging the firmware on the controller. The CSMS sends a PublishFirmwareRequest to the Local Controller specifying the remote firmware URI, an MD5 checksum, and an optional retry count. The controller downloads the file, verifies the MD5 checksum, and then makes the image available over HTTP/HTTPS/FTP on the local network. Each phase is reported to the CSMS via PublishFirmwareStatusNotification with states Downloading → Downloaded → ChecksumVerified → Published; failure paths yield DownloadFailed, InvalidChecksum, or PublishFailed. Once the status reaches Published, the notification includes the local URI(s) so the CSMS can redirect individual charging stations to the on-site copy using L01 or L02.

Messages: PublishFirmwareRequest, PublishFirmwareStatusNotification

#L04 — Unpublish Firmware file on Local Controller

Once a staged firmware image is no longer needed, the CSMS can remove it from the Local Controller by sending an UnpublishFirmwareRequest identified by the MD5 checksum of the image. The controller removes the file and responds with UnpublishFirmwareResponse; the status is Unpublished on success, NoFirmware if no matching file was found, or Downloading if a charging station is currently retrieving that image — in the last case the controller deliberately withholds deletion to avoid interrupting an in-progress update.

Messages: UnpublishFirmwareRequest

#M. Certificate Management

#M01 — Certificate installation EV

When an EV supporting ISO 15118 PnC connects and requests a new contract certificate, the charging station intercepts the CertificateInstallationReq from the EV and forwards it to the CSMS as a Get15118EVCertificateRequest with action = Install. The CSMS contacts the appropriate contract certificate pool, assembles the CertificateInstallationRes payload, and returns it in Get15118EVCertificateResponse. The charging station relays the response to the EV, completing the contract certificate installation without the CSMS needing a direct channel to the vehicle. For ISO 15118-20 sessions the message also carries a maximumContractCertificateChains field so the EV can batch-install multiple contracts in a single connection.

Messages: Get15118EVCertificate

ESCALATE: PKI-INTEGRATION — Which contract certificate pool(s) the CSMS queries and how the CSMS integrates with external provisioning services are operator/back-end design decisions.

#M02 — Certificate Update EV

When an already-provisioned EV detects that its contract certificate is approaching expiry and sends a CertificateUpdateReq (ISO 15118-2) or a CertificateInstallationReq (ISO 15118-20), the charging station forwards the request to the CSMS as a Get15118EVCertificateRequest with action = Update. The CSMS retrieves the refreshed certificate payload and returns it via Get15118EVCertificateResponse, which the charging station passes back to the EV to replace the expiring certificate. ISO 15118-20 does not distinguish install from update at the protocol level, so the charging station falls back to the M01 flow in that case.

Messages: Get15118EVCertificate

#M03 — Retrieve list of available certificates from a Charging Station

The CSMS requests an inventory of certificates currently installed in a charging station's trust store by sending GetInstalledCertificateIdsRequest with an optional certificateType filter. The charging station computes hash data for each matching certificate and returns them in GetInstalledCertificateIdsResponse; if no certificates match the filter the response status is NotFound. For V2G certificate chains, sub-CA certificates are nested as child entries under the EVSE leaf certificate in the response. The CSMS uses this information to track which roots, intermediate CAs, and leaf certificates are present before deciding whether to install or delete.

Messages: GetInstalledCertificateIds

#M04 — Delete a specific certificate from a Charging Station

The CSMS removes an individual certificate from a charging station's trust store by sending DeleteCertificateRequest with the hash data identifying the target certificate. The charging station attempts deletion and responds with DeleteCertificateResponse: Accepted on success, NotFound if the certificate is not present, or Failed if deletion is refused (for example, because it is the last certificate of its type or because it is the station's own TLS identity certificate, which cannot be removed via this path). When deleting a sub-CA or root, the charging station may also remove dependent child certificates.

Messages: DeleteCertificate

ESCALATE: LIFECYCLE-POLICY — The decision about when to remove a root or intermediate CA (e.g., during rotation vs. immediate removal) and whether to allow deletion of the last certificate of a given type is an operator policy decision.

#M05 — Install CA certificate in a Charging Station

The CSMS pushes a new root or intermediate CA certificate into a charging station's trust store by sending InstallCertificateRequest with the certificate type (CSMS root, MO root, V2G root, Manufacturer root, or others) and the DER-encoded certificate. The charging station validates and installs the certificate and responds with InstallCertificateResponse: Accepted on success, Failed on installation error, or Rejected if the certificate store capacity limit would be exceeded. When the AdditionalRootCertificateCheck configuration flag is active and a new CSMS root is installed, the existing root is temporarily retained as a fallback to avoid losing connectivity during a root rotation.

Messages: InstallCertificate

ESCALATE: ROOT-ROTATION — The timing and sequencing of CSMS root certificate rotation (including whether to use the fallback mechanism) is an operational procedure that must be coordinated between the CSO and the CSMS operator.

#M06 — Get V2G Charging Station Certificate status

ISO 15118 requires the charging station to include OCSP stapling information for its own V2G certificate during the TLS handshake with an EV, but querying an OCSP responder inline is too slow. To satisfy this constraint the charging station periodically fetches and caches the revocation status in advance by sending GetCertificateStatusRequest to the CSMS with the OCSP request data for each relevant sub-CA certificate. The CSMS contacts the appropriate OCSP responder, wraps the DER-encoded ASN.1 response, and returns it in GetCertificateStatusResponse. The charging station caches the result and refreshes it at least once a week or immediately after installing a new V2G certificate.

Messages: GetCertificateStatus

#M07 — Get Vehicle Certificate Chain Revocation Status

New in OCPP 2.1, this use case allows a charging station to verify the revocation status of the full vehicle certificate chain presented by an EV during a PnC session without the station needing direct access to external OCSP responders or CRL distribution points. The station sends GetCertificateChainStatusRequest with a list of certificate entries, each specifying hash data, the check source (OCSP or CRL), and the relevant URL(s). The CSMS checks its local cache first (valid for up to one week per ISO 15118-20) and only performs external lookups for entries not already cached; it responds with GetCertificateChainStatusResponse containing the status (Good/Revoked/Failed) and a nextUpdate timestamp for each certificate. The station caches these results locally and avoids repeat queries for entries whose nextUpdate has not expired.

Messages: GetCertificateChainStatus

#N. Diagnostics

#N01 — Retrieve Log Information

The CSMS asks a charging station to upload a log file to a given location by sending GetLogRequest, naming a log type (DiagnosticsLog, SecurityLog, or — new in OCPP 2.1 — DataCollectorLog) and an upload URL whose scheme also selects the transfer protocol. The station replies with GetLogResponse (Accepted with the file name it will use, Rejected if no matching log is available, or AcceptedCanceled if a new request supersedes an in-progress upload). It then drives the transfer asynchronously, emitting LogStatusNotificationRequest messages — Uploading, then Uploaded, or a failure status such as UploadFailure/PermissionDenied — all carrying the same requestId as the originating request. The file format is unspecified; HTTP(S) is the recommended transport, redirects must not be followed, and basic-auth credentials may be embedded in the URL userinfo. The DataCollectorLog type bulk-retrieves high-frequency measurand samples buffered by the DataCollector component, far cheaper than installing a sampling monitor.

Messages: GetLog, LogStatusNotification

ESCALATE: BACKEND-INTEGRATION — The upload endpoint, its transfer protocol, and credential handling (the spec recommends a different basic-auth password than the OCPP connection, and the log store may live outside the CSMS trust chain) are operator/back-end design decisions.

#N02 — Get Monitoring report

The CSMS retrieves the monitoring settings currently configured on a charging station by sending GetMonitoringReportRequest, optionally narrowed by monitoringCriteria (threshold, delta, or periodic monitors) and/or a list of componentVariables. The station answers GetMonitoringReportResponse with Accepted, NotSupported (for unsupported criteria), or EmptyResultSet, then streams the data back in one or more NotifyMonitoringReportRequest messages, each carrying the originating requestId and an incrementing seqNo starting at 0. Component-variable filtering follows the same wildcard expansion rules used elsewhere in the device model (a missing variable, instance, or connector matches all). In OCPP 2.1 each reported monitor also includes its eventNotificationType. The per-message item count is bounded by ItemsPerMessageGetReport.

Messages: GetMonitoringReport, NotifyMonitoringReport

#N03 — Set Monitoring Base

The CSMS activates a preconfigured set of monitors on a charging station by sending SetMonitoringBaseRequest with a monitoringBase of All, FactoryDefault, or HardWiredOnly; the station replies SetMonitoringBaseResponse with Accepted or NotSupported. HardWiredOnly disables all preconfigured monitors and removes custom ones, leaving only firmware hard-wired monitors. FactoryDefault reactivates the manufacturer's preconfigured monitors and removes all custom monitors. All activates preconfigured monitors while preserving existing custom monitors (including custom monitors created by overriding a preconfigured one). Which concrete monitors each base maps to is defined by the manufacturer.

Messages: SetMonitoringBase

#N04 — Set Variable Monitoring

The CSMS installs monitoring triggers on individual variables by sending SetVariableMonitoringRequest with a list of SetMonitoringData elements, each defining a monitor type — UpperThreshold, LowerThreshold, Delta, Periodic, PeriodicClockAligned, and (new in 2.1) TargetDelta/TargetDeltaRelative — a value, and a severity. The station returns SetVariableMonitoringResponse with one SetMonitoringResult per requested element, reporting per-monitor status: Accepted (with a station-generated id when none was supplied), UnknownComponent, UnknownVariable, UnsupportedMonitorType, Duplicate (a same-type, same-severity monitor already exists on the variable), or Rejected (e.g. threshold value outside the variable's min/max, a negative or zero Delta, an attempt to alter a hard-wired monitor, or a conflict with safety monitoring). Supplying an existing id replaces that monitor, provided the component/variable still matches; a replaced preconfigured monitor becomes a custom monitor. Monitors persist across reboot and survive firmware updates as long as the variable remains monitor-able. Batch limits come from ItemsPerMessageSetVariableMonitoring/BytesPerMessageSetVariableMonitoring.

Messages: SetVariableMonitoring

#N05 — Set Monitoring Level

To limit how much monitoring traffic a charging station reports, the CSMS sends SetMonitoringLevelRequest with a severity threshold; the station answers SetMonitoringLevelResponse with Accepted or Rejected (severity out of range). Once set, the station only raises NotifyEventRequest for monitors whose severity number is less than or equal to the configured level (lower numbers mean higher severity), suppressing less-important events — useful when the communications link must be conserved.

Messages: SetMonitoringLevel

#N06 — Clear / Remove Monitoring

The CSMS removes one or more monitors by sending ClearVariableMonitoringRequest with a list of monitor ids; the station replies ClearVariableMonitoringResponse with a clearMonitoringResult per id: Accepted, NotFound (no such id), or Rejected (the monitor cannot be cleared — e.g. a hard-wired monitor). The number of ids per request is bounded by ItemsPerMessageClearVariableMonitoring/BytesPerMessageClearVariableMonitoring; exceeding either may draw a CALLERROR (OccurenceConstraintViolation or FormatViolation).

Messages: ClearVariableMonitoring

#N07 — Alert Event

When a threshold or delta monitor trips, the charging station reports it to the CSMS with NotifyEventRequest, including only the component/variable/variableMonitoringId combinations responsible for the event and the trigger reason (Alerting for thresholds and the new TargetDelta/TargetDeltaRelative types, Delta for delta monitors). When a monitored value returns within bounds the station sends a follow-up event with cleared = true. The CSMS always answers with an empty NotifyEventResponse. Events at or below OfflineMonitoringEventQueuingSeverity are queued while the station is offline and delivered on reconnect; higher-severity events triggered while offline may be dropped, so the CSMS must tolerate a cleared notification for a condition whose onset it never saw. In OCPP 2.1, hard-wired notifications carry an implementation-defined severity, and threshold modifications/removals have explicit rules for whether a cleared event is emitted.

Messages: NotifyEvent

#N08 — Periodic Event

For monitors of type Periodic or PeriodicClockAligned, the charging station emits NotifyEventRequest at the configured cadence with trigger = Periodic, rather than waiting for a threshold breach. Periodic counts seconds from when the monitor was set or last fired; PeriodicClockAligned aligns to wall-clock boundaries (e.g. a value of 900 fires at :00, :15, :30, :45 each hour). The first or only report part has seqNo = 0, the CSMS responds with an empty NotifyEventResponse, and offline queuing follows the same OfflineMonitoringEventQueueingSeverity rule as N07. For high-frequency periodic monitors the more efficient event-stream mechanism of N11–N15 is preferred.

Messages: NotifyEvent

#N09 — Get Customer Information

To satisfy privacy requests, the CSMS retrieves the raw data a charging station holds about a customer by sending CustomerInformationRequest with report = true and exactly one customer reference — an idToken, a customerCertificate, or a free-form customerIdentifier. The station answers CustomerInformationResponse with Accepted, Rejected (cannot process now), or Invalid (zero or more than one reference supplied), then returns the data in one or more NotifyCustomerInformationRequest messages (an empty data string if nothing is stored), each acknowledged by NotifyCustomerInformationResponse. When referencing by certificate, the CSMS must use the same hash algorithm that was used to install it.

Messages: CustomerInformation, NotifyCustomerInformation

#N10 — Clear Customer Information

This is the erasure counterpart to N09: the CSMS sends CustomerInformationRequest with clear = true (and report either true or false) plus a single customer reference. The station responds CustomerInformationResponse (Accepted/Rejected) and then removes all data it holds about that customer except the Local Authorization List — which only the CSMS may change, via SendLocalListRequest (see D01) to avoid version conflicts. If report = true the cleared data is streamed back in NotifyCustomerInformationRequest messages (or one message indicating no data was found); if report = false a single notification confirms the data was cleared. Setting both report and clear to false should be rejected. As with N09, certificate references must use the install-time hash algorithm.

Messages: CustomerInformation, NotifyCustomerInformation

ESCALATE: PRIVACY-POLICY — Which data items constitute "customer related data," how erasure is enforced across back-end systems, and how the resulting Local Authorization List update is coordinated are operator/legal-compliance decisions.

#N11 — Set Frequent Periodic Variable Monitoring

New in OCPP 2.1, this use case sets up an efficient "event stream" for monitors expected to fire frequently (typically Periodic/PeriodicClockAligned, but also frequent Delta monitors), so that many values can be batched into a single unconfirmed message instead of one NotifyEventRequest each. In the CSMS-driven path, SetVariableMonitoringRequest carries a periodicEventStream element (with interval and/or values flush parameters) per monitor; after responding with SetVariableMonitoringResponse, the station opens a stream for each such monitor by sending OpenPeriodicEventStreamRequest (the constant per-monitor data plus the variableMonitoringId), which the CSMS accepts or rejects via OpenPeriodicEventStreamResponse. A station may also open a stream on its own for hard-wired or preconfigured periodic monitors. The CSMS associates the stream's static fields (variableMonitoringId, trigger=Periodic, eventNotificationType, severity, component, variable) with subsequent stream data. If the CSMS rejects the stream, the station falls back to ordinary NotifyEventRequest reporting. See the Periodic Event Stream Lifecycle sequence and the Smart Charging deltas doc.

Messages: SetVariableMonitoring, OpenPeriodicEventStream, NotifyPeriodicEventStream

#N12 — Get Periodic Event Streams

New in OCPP 2.1, this lets the CSMS recover its inventory of open event streams — needed only if it has lost track of them. The CSMS sends GetPeriodicEventStreamRequest (no parameters) and the station replies GetPeriodicEventStreamResponse with a list of zero or more ConstantStreamData entries, one per currently open stream.

Messages: GetPeriodicEventStream

#N13 — Close Periodic Event Streams

New in OCPP 2.1, this terminates an event stream. The charging station may close a stream at any time: it first flushes all buffered values, then sends ClosePeriodicEventStreamRequest with the stream id (acknowledged by ClosePeriodicEventStreamResponse) and reverts to ordinary NotifyEventRequest reporting for that variable. Closing is normally a consequence of the CSMS removing the monitor: a ClearVariableMonitoringRequest (N06) that clears a monitor backed by a stream, or a SetVariableMonitoringRequest that replaces the monitor without a periodicEventStream element, automatically closes the associated stream. See the Periodic Event Stream Lifecycle sequence.

Messages: ClosePeriodicEventStream, ClearVariableMonitoring, SetVariableMonitoring

#N14 — Adjust Periodic Event Streams

New in OCPP 2.1, this lets the CSMS retune how often a stream flushes without tearing it down. The CSMS sends AdjustPeriodicEventStreamRequest with the stream id and a params object carrying new interval and/or values values; the station answers AdjustPeriodicEventStreamResponse with Accepted (and changes its NotifyPeriodicEventStream cadence accordingly) or Rejected if it cannot comply. This pairs with N15.FR.05, where a growing pending count signals the CSMS to consider larger or more frequent messages.

Messages: AdjustPeriodicEventStream

#N15 — Periodic Event Streams

New in OCPP 2.1, this describes the actual data transfer over an open stream. As a monitor produces values, the charging station buffers each with a timestamp and flushes the buffer once params.interval seconds have elapsed since the last flush or once params.values values have accumulated, writing them as a NotifyPeriodicEventStream message. This message uses the new RPC "SEND" message type — it is unconfirmed: the CSMS does not return a CALLRESULT/CALLERROR, which allows the station to send without waiting and greatly reduces overhead. Each message carries a basetime set to the timestamp of its first value (so that value's offset t is 0), a list of StreamDataElement entries (value v and time offset t), and a pending count of values buffered but not yet sent. The CSMS recombines this with the monitor's static data (variableMonitoringId, trigger, eventNotificationType, severity, component, variable) to reconstruct what a NotifyEventRequest would have carried; the only absent required field, eventId, may be assigned any value since it is never sent back. Because there is no reply, the CSMS cannot signal errors over the stream — its only recourse is to clear the associated monitor (N06/N13). See the RPC SEND framing in Part 4 / the Sequences doc.

Messages: NotifyPeriodicEventStream

#O. Display Message

#O01 — Set DisplayMessage

The CSMS pushes a custom message to a charging station's display by sending SetDisplayMessageRequest with a unique ID, the message content (optionally in multiple languages via the messageExtra field), a priority (NormalCycle, InFront, or AlwaysFront), an optional display state, optional start/end time window, and an optional target display identifier for stations with multiple screens. The charging station stores the message persistently so it survives power cycles, and responds Accepted or rejects with a specific status code such as NotSupportedPriority, NotSupportedState, NotSupportedMessageFormat, LanguageNotSupported (when DisplayMessageLanguage is configured and the message language is not in the allowed list), or Rejected when the station's message capacity is full. In OCPP 2.1, the DisplayMessageLanguage configuration variable governs which language tags are accepted, and multi-display targeting is supported via the display element in MessageInfoType. Language tags must conform to RFC 5646.

Messages: SetDisplayMessage

ESCALATE: DISPLAY-POLICY — Which priorities, states, and message formats a station supports, and what maximum message count is configured, are vendor/operator configuration decisions.

#O02 — Set DisplayMessage for Transaction

When a CSO wants to show a message on the display only while a specific transaction is active, the CSMS sends SetDisplayMessageRequest with the relevant transactionId included in the message object. Behaviour is otherwise identical to O01 — the charging station stores and displays the message according to its priority and timing parameters — but with the additional rule that the message is automatically discarded as soon as the referenced transaction ends. If the charging station does not recognise the supplied transaction ID it immediately responds UnknownTransaction. This prevents orphaned messages from remaining on screen after a session has closed.

Messages: SetDisplayMessage

#O03 — Get All DisplayMessages

The CSMS retrieves the complete list of OCPP-configured messages currently stored in a charging station by sending GetDisplayMessagesRequest with all filter fields omitted (i.e. requesting everything). The station responds immediately with GetDisplayMessagesResponse — Accepted if at least one message is configured, Unknown if none are present — and then streams the full message inventory in one or more NotifyDisplayMessagesRequest batches. When the list spans multiple batches, the tbc (to be continued) flag is set to true on all but the last NotifyDisplayMessages message. The requestId field ties all notifications back to the original query. Only messages that were set via OCPP can be retrieved; firmware-built-in messages are not visible through this flow.

Messages: GetDisplayMessages, NotifyDisplayMessages

#O04 — Get Specific DisplayMessages

The CSMS queries a subset of OCPP-configured messages by sending GetDisplayMessagesRequest with one or more filter fields populated (e.g., message ID, priority, or state). The charging station checks whether any stored messages match the supplied criteria: if matches exist it responds Accepted and delivers the results in one or more NotifyDisplayMessagesRequest messages using the same batching and tbc mechanism as O03; if no messages match the filter the station responds Unknown and sends no notifications. This use case is useful for confirming that a specific message is still active or for auditing messages by priority class without pulling the entire list.

Messages: GetDisplayMessages, NotifyDisplayMessages

#O05 — Clear a DisplayMessage

The CSMS removes a specific OCPP-managed message from a charging station by sending ClearDisplayMessageRequest with the numeric ID of the message to remove. The charging station deletes the matching message and responds with ClearDisplayMessageResponse: Accepted if the message was found and removed, Unknown if no message with that ID exists, or Rejected (added in OCPP 2.1) if the station is unable to process the request. Only messages that were originally installed via OCPP can be cleared through this mechanism; firmware-resident messages are unaffected.

Messages: ClearDisplayMessage

#O06 — Replace DisplayMessage

When the CSMS needs to update the content or parameters of a message that already exists on a charging station, it sends a SetDisplayMessageRequest reusing the same message ID as the message to be replaced. The charging station matches the incoming ID to the stored message, replaces both the content and all parameters (priority, state, timing, language, etc.) atomically with the new values, and responds Accepted. This differs from O01 in that a pre-existing entry with the same ID is a prerequisite; the use case avoids having to delete-then-re-add when refreshing a message.

Messages: SetDisplayMessage

#P. Data Transfer

#P01 — Data Transfer to the Charging Station

When the CSMS needs to exchange information with a charging station for a function that falls outside the standardised OCPP message set, it sends DataTransferRequest to the station carrying a vendorId (a reversed-DNS name uniquely identifying the vendor), an optional messageId indicating the specific operation, and an optional free-form data payload. The charging station processes the request according to the bilateral agreement with the CSMS vendor and responds with DataTransferResponse; if it has no implementation for the specified vendorId it must respond UnknownVendor, and a messageId mismatch yields UnknownMessageId. The Accepted or Rejected meaning of the response status, and the structure of the data field, are entirely vendor-specific. Data Transfer is not intended for standard production use and the spec strongly cautions that it risks interoperability with systems that do not support the same extension.

Messages: DataTransfer

ESCALATE: VENDOR-EXTENSION — The vendorId, messageId, and data semantics are a bilateral vendor agreement and must be documented separately outside of OCPP; the decision to use Data Transfer at all is a deployment/architecture policy choice.

#P02 — Data Transfer to the CSMS

The mirror of P01: when a charging station needs to send information to the CSMS for a function not covered by standard OCPP, it initiates DataTransferRequest with its own vendorId, an optional messageId, and an optional data payload. The CSMS responds with DataTransferResponse; if it has no implementation for the vendorId it responds UnknownVendor. As with P01, the interpretation of Accepted/Rejected and the data content are governed entirely by the vendor-specific bilateral agreement, and the payload length is undefined and should be agreed upon by both parties in advance.

Messages: DataTransfer

ESCALATE: VENDOR-EXTENSION — Same bilateral vendor agreement requirement as P01; payload length limits should be agreed between the charging station and CSMS vendor before deployment.

#Q. Bidirectional Power Transfer (V2X)

Block Q introduces bidirectional power transfer (V2X) — the EV exporting energy back to the grid as well as importing it. The control surface is the existing smart-charging machinery extended with an operationMode field on each charging-schedule period and signed setpoint/dischargeLimit values. For the conceptual model, the operation-mode catalogue, and how V2X profiles merge with ordinary limits, see the Bidirectional Power Transfer deep-dive and the Smart Charging deep-dive.

#Q01 — V2X Authorization

When an ISO 15118-20 EV is authorized for bidirectional transfer, the station includes the vehicle's EVCCID in the idToken.additionalInfo of AuthorizeRequest so the CSMS can decide whether to allow V2X for this vehicle; the CSMS answers with idTokenInfo.status = Accepted and an allowedEnergyTransfer list naming the permitted transfer types (e.g. DC_BPT, AC_BPT). The station then opens a transaction and reports the EV's chosen requestedEnergyTransfer together with v2xChargingParameters, controlMode and an optional departureTime via NotifyEVChargingNeeds; the CSMS accepts (optionally Processing while it computes a profile) or rejects, in which case the station either renegotiates a different service with the EV or stops the transaction with stoppedReason = ReqEnergyTransferRejected. A V2X-mode charging schedule arrives by SetChargingProfile (or a pre-installed TxDefaultProfile, signalled by a NoChargingProfile response). If the allowed set changes mid-session, the CSMS pushes NotifyAllowedEnergyTransfer.

Messages: Authorize, TransactionEvent, NotifyEVChargingNeeds, SetChargingProfile, NotifyAllowedEnergyTransfer

ESCALATE: GRID-MARKET — Whether a given vehicle (by idToken, EVCCID or vehicle certificate) is permitted to perform V2X, and whether third-party (eMSP/aggregator) authorization must be obtained before granting it, is an operator/market-contract decision outside the protocol.

#Q02 — Starting in operationMode ChargingOnly before enabling V2X

This use case covers the common situation where, at authorization time, the CSMS cannot yet confirm whether V2X is allowed (for example because a third-party permission or the selected EVSE is not yet known). The CSMS accepts the authorization but omits allowedEnergyTransfer, and the session begins in operationMode = ChargingOnly — an ordinary unidirectional charge with no setpoint/dischargeLimit fields set. Once the CSMS later decides V2X is permitted (using the EVCCID, vehicle certificate, or idToken it has on file), it sends NotifyAllowedEnergyTransfer carrying the transaction id and an updated list that now includes a bidirectional type; the station accepts and triggers an ISO 15118 service renegotiation so the EV can upgrade to the bidirectional service, after which a new NotifyEVChargingNeeds reports the upgraded requestedEnergyTransfer.

Messages: Authorize, NotifyEVChargingNeeds, SetChargingProfile, NotifyAllowedEnergyTransfer

#Q03 — Central V2X control with charging schedule

The CSMS dictates the EV's charge/discharge behaviour by sending a TxProfile or TxDefaultProfile whose chargingSchedule contains one or more periods with operationMode = CentralSetpoint and a (signed) setpoint for the active power the EV should import (positive) or export (negative); it may also bound the range with limit and dischargeLimit. In ISO 15118 Scheduled mode the station hands the schedule to the EV and any change triggers a 15118 renegotiation; in Dynamic mode the station simply applies the period's setpoint at each boundary without renegotiation. For a Dynamic profile kind the CSMS can later revise the setpoint with UpdateDynamicSchedule. How long the schedule survives an offline period is governed by maxOfflineDuration/invalidAfterOfflineDuration (see Q11/Q12).

Messages: SetChargingProfile, UpdateDynamicSchedule, TransactionEvent

#Q04 — Central V2X control with dynamic CSMS setpoint

A variant of Q03 in which, instead of a multi-period schedule, the CSMS sends a Dynamic profile holding a single chargingSchedulePeriod (again operationMode = CentralSetpoint) and then steers it in near-real-time with frequent UpdateDynamicSchedule messages — suited to following an external dispatch signal. The optional chargingSchedule.duration acts as a watchdog: if no update arrives within duration seconds of the last SetChargingProfile/UpdateDynamicSchedule, the schedule expires and the station falls back to the next valid charging profile. As an alternative the station may pull updates itself via PullDynamicScheduleUpdate on the configured dynUpdateInterval.

Messages: SetChargingProfile, UpdateDynamicSchedule, PullDynamicScheduleUpdate

#Q05 — External V2X setpoint control with a charging profile from CSMS

Here the CSMS explicitly delegates real-time control to an External System (e.g. a local EMS) but only inside a window it defines. The CSMS sends a Dynamic TxProfile/TxDefaultProfile whose period carries operationMode = ExternalSetpoint (External System drives setpoint/setpointReactive) or ExternalLimits (it drives limit/dischargeLimit). During that period the station applies values supplied by the external system and stamps dynUpdateTime on each change; the configuration variable ExternalConstraintsProfileDisallowed = true ensures the external system cannot otherwise impose its own profile. If chargingSchedule.duration is set and no external update arrives in time, the profile becomes invalid and the station falls back, regaining validity once a fresh update is received. The transport between the External System and the station is out of OCPP scope.

Messages: SetChargingProfile

ESCALATE: VENDOR-EXTENSION — The communication channel and protocol by which the External System conveys setpoints/limits to the Charging Station is explicitly out of scope of OCPP and is a vendor/integration decision.

#Q06 — External V2X control with a charging profile from an External System

Unlike Q05, here the External System itself owns the profile: it installs a ChargingStationExternalConstraints charging profile (possible only when ExternalConstraintsProfileDisallowed is false/absent). Three flavours exist — a scheduled list of limits (Absolute, ExternalLimits), a dynamically-varied single limit (Dynamic, ExternalLimits), or a dynamically-varied setpoint (Dynamic, ExternalSetpoint). Because an external system is unaware of individual sessions, such a profile typically targets EVSE #0 (the whole station), which must then divide charge/discharge power across its EVSEs to honour the aggregate limit/dischargeLimit/setpoint. When the profile is set or changes by more than LimitChangeSignificance, the station reports it to the CSMS with NotifyChargingLimit (chargingLimitSource = EMS). When both an external setpoint and a Tx(Default)Profile setpoint are active, SmartChargingCtrlr.SetpointPriority resolves which wins.

Messages: SetChargingProfile

ESCALATE: VENDOR-EXTENSION — How the External System delivers its ChargingStationExternalConstraints profile to the station is out of OCPP scope; whether external profiles are allowed at all (ExternalConstraintsProfileDisallowed) and the SetpointPriority tie-break are operator configuration choices.

#Q07 — Central V2X control for frequency support

A specialisation of Q04 for grid frequency regulation when calibrated central frequency measurements are needed. The CSMS sends a Dynamic profile with a single period of operationMode = CentralFrequency and a setpoint, then continuously revises it with UpdateDynamicSchedule as it tracks the centrally-measured frequency (usually for an aggregated fleet). limit/dischargeLimit must not appear in a CentralFrequency period, and the CSMS is advised to set a duration so the schedule does not run forever if updates stop — at which point the station can fall back to a lower-stack-level LocalFrequency profile (Q08). This frequency support is the charging profile's primary purpose, distinct from the grid-code frequency-droop behaviour configured under DER Control (block R).

Messages: SetChargingProfile, UpdateDynamicSchedule

#Q08 — Local V2X control for frequency support

Frequency support computed locally by the station from its own frequency readings, with no live setpoint from the CSMS. The CSMS sends a LocalFrequency schedule carrying a v2xBaseline power and a v2xFreqWattCurve (at least two points); the station continuously measures grid frequency and sets power to the baseline plus the curve-interpolated value, re-evaluating whenever the frequency moves by LocalFrequencyUpdateThreshold mHz. For an aFRR (automatic Frequency Restoration Reserve) service the schedule also includes a v2xSignalWattCurve, and the CSMS relays the TSO's dispatch via AFRRSignal (a signal plus a timestamp at which it applies); the station adds that delta on top of the frequency-watt setpoint. The schedule must use chargingRateUnit = W, and missing curves are rejected with NoFreqWattCurve/NoSignalWattCurve.

Messages: SetChargingProfile, AFRRSignal

ESCALATE: GRID-MARKET — The frequency-watt and signal-watt curves, the baseline, and the source/meaning of the aFRR signal forwarded to the station are dictated by the TSO/grid-code and market product the operator is participating in.

#Q09 — Local V2X control for load balancing

The station is given a LocalLoadBalancing schedule and continuously reads an upstream (building/site) grid meter to keep the measured load between a configured LowerThreshold and UpperThreshold, modulating the EV's charge/discharge setpoint by the computed delta (with optional UpperOffset/LowerOffset to control permitted overshoot). It rejects the profile with UnsupportedParam if LocalLoadBalancing is not in V2XSupportedOperationModes, or MissingDevModelInfo if the threshold/offset variables are unset or inconsistent. The resulting setpoint is capped at limit/dischargeLimit when those are present. This works for a single station (possibly across its EVSEs); coordinating multiple stations requires a central or local controller using the CentralSetpoint mode instead.

Messages: SetChargingProfile

#Q10 — Idle, minimizing energy consumption

An operationMode = Idle schedule period asks the EV to neither charge nor discharge while the session stays connected. Two boolean controls modulate the period: preconditioning = true permits the EV to draw some power to keep its battery at an optimal temperature for later charge/discharge, and evseSleep = true (only if SupportsEvseSleep) lets the station power down the EVSE's electronics for this transaction until an event wakes it (a new period, a new profile — including 0 W limits — or transaction end). While asleep the station reports evseSleep = true in TransactionEvent. A period with operationMode = Idle must not carry any limit/dischargeLimit/setpoint/setpointReactive, otherwise the profile is rejected with InvalidSchedule.

Messages: SetChargingProfile, TransactionEvent

#Q11 — Going offline during V2X operation

This use case defines how long a V2X session may continue once the station loses its CSMS connection. The maxOfflineDuration field of the active ChargingProfileType sets a countdown that starts the moment the station detects it is offline; when it elapses the station reverts to the next valid (lower stack-level) profile — which may itself be another V2X profile if its own maxOfflineDuration has not run out, or ultimately a ChargingOnly fallback or unlimited charging if nothing remains. The CSMS should simply assume the V2X operation has reverted on detecting the outage rather than trying to predict the exact instant, since the two sides notice the disconnection at different times. Profiles with invalidAfterOfflineDuration = true whose window has elapsed are not reactivated on reconnection. The requirements are those of K01's maxOfflineDuration.

Messages: SetChargingProfile

#Q12 — Resuming a V2X operation after an offline period

The mirror of Q11, describing the state on reconnection. If the offline interval was shorter than the V2X profile's maxOfflineDuration, the profile stayed active throughout and nothing changes when the link returns. If it was longer, the profile had already expired while offline and the station has been running on the next valid (lower stack-level) profile — for instance reverting from a CentralSetpoint V2X profile at stack level #2 to a ChargingOnly profile at level #1; whether it can be resumed depends on invalidAfterOfflineDuration. On reconnection the CSMS can re-establish the desired V2X mode by re-sending or updating the relevant charging profile.

Messages: SetChargingProfile, UpdateDynamicSchedule

#R. DER Control

Block R covers Distributed Energy Resource (DER) controls — grid-code behaviours such as Volt-Watt and Volt-Var curves, frequency droop, ride-through (must-trip / may-trip) and discharge-power limits — that a utility mandates for bidirectional sessions to protect the grid. These satisfy grid-code obligations and are conceptually separate from the V2X frequency-support use cases of block Q. For the control catalogue, curve types, default-vs-scheduled priority model and alarm semantics, see the DER Control deep-dive. The DER control may be enforced by the inverter in the EVSE, by the inverter in the EV, or split between them.

#R01 — Starting a V2X session with DER control in EVSE

When the inverter sits in the EVSE — always the case for DC (ISO 15118-20 DC_BPT, CHAdeMO) and possible for AC AC_BPT where the station controls the EV's power via the charge loop — the station enforces the utility's DER controls itself and the EV needs no DER configuration. Beforehand the CSMS installs the controls (e.g. a VoltWatt curve and a LimitMaxDischarge of 50 %) with SetDERControl, which the station must store persistently; a DC station exposes its inverter nameplate capabilities in the DCDERCtrlr component (reportable via the device model). The bidirectional session then proceeds as an ordinary V2X transaction (NotifyEVChargingNeeds → SetChargingProfile TxProfile), with the station continuously applying the curves and discharge limit during the charge loop.

Messages: SetDERControl, NotifyEVChargingNeeds, SetChargingProfile

ESCALATE: GRID-MARKET — Which DER controls (curves, droop parameters, discharge limits) apply and their values are dictated by the utility/grid code for the station's region, not by the protocol.

#R02 — Starting a V2X session with DER control in EV

For an AC AC_BPT_DER session the inverter is inside the EV and the station cannot operate it directly; instead the station passes the DER controls down to the EV to execute. The CSMS still installs the controls with SetDERControl (persisted by the station), but because they are not listed in ACDERCtrlr.ModesSupported the station forwards them to the EV during ISO 15118-20 ChargeParameterDiscovery, and reports the EV inverter's nameplate and supported-control list to the CSMS in the derChargingParameters of NotifyEVChargingNeeds. When a control acts on the session (e.g. a high-frequency trip or a discharge-power cap), the EV signals the station via the 15118 DERAlarm element and the station forwards it to the CSMS with NotifyDERAlarm.

Messages: SetDERControl, NotifyEVChargingNeeds, SetChargingProfile, NotifyDERAlarm

ESCALATE: GRID-MARKET — The set of DER controls the EV must support for AC_BPT_DER (advertised via DERControlFunctions in service negotiation) and their values reflect the utility's grid-code requirements.

#R03 — Starting a V2X session with hybrid DER control in both EV and EVSE

A blend of R01 and R02 for AC_BPT_DER sessions where the EV's inverter supports only some of the required controls. The station advertises the controls it can emulate locally (via the charge loop) in ACDERCtrlr.ModesSupported; for those it can emulate it may omit them from the 15118 AC_BPT_DER service negotiation, letting an EV with a less-capable inverter still participate. Controls the EV does support are configured in the EV (the station does not emulate what the EV can do natively), while the remainder are enforced by the station. As in R02 the station persists the SetDERControl settings, reports EV nameplate data in NotifyEVChargingNeeds, and raises NotifyDERAlarm whenever any control — whether executed by EV or EVSE — affects the session.

Messages: SetDERControl, NotifyEVChargingNeeds, SetChargingProfile, NotifyDERAlarm

#R04 — Configure DER control settings at Charging Station

The management workflow for DER controls. The CSMS configures a control with SetDERControl, marking it either a default (isDefault = true, no startTime/duration, takes effect immediately) or a scheduled control (isDefault = false, with a startTime/duration). Each controlType (e.g. FreqDroop, VoltVar, VoltWatt, HFMustTrip, HFMayTrip, LimitMaxDischarge, EnterService, Gradients) must carry exactly its matching control field and, for curve types, the yUnit prescribed for that type; EnterService and Gradients exist only as defaults. Conflicts are resolved by a numeric priority (lower value wins): a higher-priority new control supersedes the existing one (which gets isSuperseded = true and is named via supersededId), while a lower-priority new control is itself immediately superseded. The station deletes scheduled controls after startTime + duration, reverts to the default when no scheduled control is active, and reports start/stop of scheduled controls with NotifyDERStartStop. The CSMS reads back configured controls with GetDERControl (filtering by isDefault/controlType/controlId), which the station answers with one or more paged ReportDERControl messages (tbc flag set on all but the last), and removes them with ClearDERControl.

Messages: SetDERControl, GetDERControl, ReportDERControl, ClearDERControl, NotifyDERStartStop

ESCALATE: GRID-MARKET — The DER programs, curve points, droop parameters and their relative priorities originate from the utility/grid code; the CSMS merely relays the highest-priority applicable control to each station.

#R05 — Charging station reporting a DER event

When a grid anomaly forces the station to deviate from the active charging profile because of a DER control — for example an overvoltage that makes a configured VoltWatt curve reduce discharge power — the station reports the event once per occurrence with NotifyDERAlarm, setting the controlType (e.g. VoltWatt) and the gridEventFault (e.g. OverVoltage) together with a timestamp. A DC station then lowers discharge power per the curve directly; an AC station instructs the EV via repeated 15118 AC_ChargeLoop messages each time the curve value changes. When conditions return to normal the station sends a closing NotifyDERAlarm with alarmEnded = true and resumes following the charging profile. (Purely reactive-power actions such as Volt-Var are not reported unless they affect the session's active-power profile.)

Messages: NotifyDERAlarm

#S. Battery Swapping

Block S models a battery-swap station (BSS) as an ordinary OCPP Charging Station in which each battery slot is a logical EVSE. The swap dialogue (recording which pack went in and which came out) uses the dedicated BatterySwap/RequestBatterySwap messages, while the subsequent recharging of the returned packs is plain transaction handling. See the swap event ordering walkthrough in the Sequences deep-dive.

#S01 — Battery Swap Local Authorization

The driver authorizes locally at the swap station by presenting an RFID card; the station sends Authorize and, on idTokenInfo.status = Accepted (and provided enough charged packs are available), opens or indicates the empty slot(s) into which the depleted pack(s) can be inserted. This mirrors ordinary RFID authorization (use case C01), except that the authorization does not start a transaction, so C01's transaction-in-progress rules do not apply. If the driver fails to insert a battery before the BatterySwapInTimeout expires, the station ends the authorization and aborts the swap (no BatterySwap message having been sent yet); if too few charged packs are on hand, the swap is refused.

Messages: Authorize

#S02 — Battery Swap Remote Start

The remote-initiated counterpart of S01: the driver triggers the swap from a smartphone app (e.g. scanning a QR code), and the CSMS — having authorized the token — sends RequestBatterySwap carrying the idToken and a requestId. If enough charged packs are available the station answers Accepted; otherwise it returns Rejected with reasonCode = NoBatteryAvailable. The requestId from this request must be reused in the BatterySwap events that follow (S03), letting the CSMS correlate the swap with its originating request. As in S01, failure to insert a pack before BatterySwapInTimeout aborts the process.

Messages: RequestBatterySwap, BatterySwap

#S03 — Battery Swap In/Out

This use case records the physical exchange. In the default In-Out order the driver (or swapping machinery) first inserts the depleted pack(s) into empty slot(s), and the station sends BatterySwap with eventType = BatteryIn, the shared requestId, the authorized idToken, and a batteryData entry per pack (slot evseId, serialNumber, SoC, SoH); it then reports each slot's connector as Occupied via NotifyEvent. The station then offers charged pack(s); when the driver takes them out the station sends a second BatterySwap with eventType = BatteryOut, the same requestId and the data of the extracted pack(s), and reports those slots Available. If a charged pack offered after the BatteryIn is not collected within BatterySwapOutTimeout, the station sends a BatterySwap with eventType = BatteryOutTimeout so the CSMS does not retain an orphan BatteryIn with no matching BatteryOut. A station that swaps in the reverse order reports BatterySwapCtrlr.SwapOrder = Out-In. The BatterySwapResponse has no rejection status, so a CSMS that needs to reject an inserted pack must use the org.openchargealliance.batteryswapresponse customData extension.

Messages: BatterySwap, NotifyEvent, TransactionEvent

ESCALATE: VENDOR-EXTENSION — Rejecting an inserted battery requires the bilateral org.openchargealliance.batteryswapresponse customData extension (reason codes such as BatterySoHLow, BatteryDamaged, BatteryUnknown); whether a station implements it is a vendor decision flagged via CustomizationCtrlr.CustomImplementationEnabled.

#S04 — Battery Swap Charging

After a depleted pack is inserted, the station recharges it as a normal transaction on that slot's logical EVSE. With TxStartPoint/TxStopPoint configured to EVConnected, inserting the pack opens a transaction: TransactionEvent with eventType = Started, triggerReason = CablePluggedIn (meaning the pack was inserted) and either the predefined BatterySwapIdtoken (type Central) or an empty token (type NoAuthorization). The station then sends periodic TransactionEvent updates carrying the battery's SoC measurand; the pack becomes eligible for swapping at BatterySwapTargetSoc and, on reaching BatterySwapMaxSoc (which must be ≥ the target), the station suspends energy transfer with chargingState = SuspendedEVSE and triggerReason = EnergyLimitReached, keeping the transaction alive so charging can resume (e.g. for V2X). Removing the pack ends the transaction (eventType = Ended, stoppedReason = EVDisconnected). After a reboot the station restarts transactions for every slot still holding a battery. These transaction messages are not tied to the driver's idToken.

Messages: TransactionEvent

#How This Document Was Produced

#A. Security

#A01 — Update Charging Station Password for HTTP Basic Authentication

#A02 — Update Charging Station Certificate by request of CSMS

#A03 — Update Charging Station Certificate initiated by the Charging Station

#A04 — Security Event Notification

#A05 — Upgrade Charging Station Security Profile

#B. Provisioning

#B01 — Cold Boot Charging Station

#B02 — Cold Boot Charging Station - Pending

#B03 — Cold Boot Charging Station - Rejected

#B04 — Offline Behavior Idle Charging Station

#B05 — Set Variables

#B06 — Get Variables

#B07 — Get Base Report

#B08 — Get Custom Report

#B09 — Setting a new NetworkConnectionProfile

#B10 — Migrate to new CSMS

#B11 — Reset - Without Ongoing Transaction

#B12 — Reset - With Ongoing Transaction

#B13 — Reset - With Ongoing Transaction - Resuming Transaction

#C. Authorization

#C01 — EV Driver Authorization using RFID

#C02 — Authorization using a start button

#C03 — Authorization using credit/debit card

#C04 — Authorization using PIN-code

#C05 — Authorization for CSMS initiated transactions

#C06 — Authorization using local id type

#C07 — Authorization using Contract Certificates

#C08 — Authorization at EVSE using ISO 15118 External Identification Means (EIM)

#C09 — Authorization by GroupId

#C10 — Store Authorization Data in the Authorization Cache

#C11 — Clear Authorization Data in Authorization Cache

#C12 — Start Transaction - Cached Id

#C13 — Offline Authorization through Local Authorization List

#C14 — Online Authorization through Local Authorization List

#C15 — Offline Authorization of unknown Id

#C16 — Stop Transaction with a Master Pass

#C17 — Authorization with prepaid card

#C18 — Authorization using locally connected payment terminal

#C19 — Cancellation prior to transaction

#C20 — Cancellation after start of transaction

#C21 — Settlement at end of transaction

#C22 — Settlement is rejected or fails

#C23 — Increasing authorization amount

#C24 — Ad hoc payment via stand-alone payment terminal

#C25 — Ad hoc payment via a QR code

#D. Local Authorization List Management

#D01 — Send Local Authorization List

#D02 — Get Local List Version

#E. Transactions

#E01 — Start Transaction options

#E02 — Start Transaction - Cable Plugin First

#E03 — Start Transaction - IdToken First

#E04 — Transaction started while Charging Station is offline

#E05 — Start Transaction - Id not Accepted

#E06 — Stop Transaction options

#E07 — Transaction locally stopped by IdToken

#E08 — Transaction stopped while Charging Station is offline

#E09 — When cable disconnected on EV-side: Stop Transaction

#E10 — When cable disconnected on EV-side: Suspend Transaction

#E11 — Connection Loss During Transaction

#E12 — Inform CSMS of an Offline Occurred Transaction

#E13 — Transaction-related message not accepted by CSMS

#E14 — Check transaction status

#E15 — End of charging process

#E16 — Transactions with fixed cost, energy, SoC or time

#E17 — Resuming transaction after forced reboot

#F. Remote Control

#F01 — Remote Start Transaction - Cable Plugin First

#F02 — Remote Start Transaction - Remote Start First

#F03 — Remote Stop Transaction

#F04 — Remote Stop ISO 15118 Charging from CSMS

#F05 — Remotely Unlock Connector

#F06 — Trigger Message

#F07 — Remote start with fixed cost, energy, SoC or time

#G. Availability

#G01 — Report connector AvailabilityState

#G02 — Heartbeat

#G03 — Change Availability EVSE/Connector