OCPP 2.0.1 — Operational Message Flows

Purpose: Step-by-step message flows for operational OCPP 2.0.1 scenarios: reservations, offline behavior, firmware updates, and report pagination. Optimized for AI agent consumption. Complements the core flows document (boot, auth, transactions).

Last updated: 2026-02-07

#How This Document Was Produced

This document covers operational OCPP 2.0.1 message flows: reservations, offline queueing and replay, firmware updates, and report pagination. Its dominant confidence tier is spec-knowledge — behavioral sequences from the OCPP 2.0.1 specification Part 2, known via AI training data. Firmware status enum values are schema-derived (cross-referenced against the schema documentation and data types reference, mechanically extracted from the official OCA JSON schemas). The reconnection backoff formula (§2.3) is spec-knowledge.

This document contains 2 escalation points marked with > **ESCALATE:**. When an AI agent encounters one, it MUST stop and ask the developer to make the decision. See METHODOLOGY.md for the full confidence and escalation model.

Companion documents:

• Core Flows — boot, authorization, transaction lifecycle
• Reservation Schemas — ReserveNow, CancelReservation, ReservationStatusUpdate field-level details
• Firmware Schemas — UpdateFirmware, FirmwareStatusNotification field-level details
• Provisioning Schemas — GetBaseReport, NotifyReport field-level details
• Diagnostics Schemas — GetLog, LogStatusNotification, monitoring
• Data Types Reference — IdTokenType, IdTokenInfoType, EVSEType

#1. Reservation → Transaction

Reservations hold an EVSE for a specific user within a time window. Requires ReservationCtrlr.Enabled = true.

For field schemas: ReserveNow, CancelReservation, ReservationStatusUpdate.

#1.1 Making a Reservation

1. CSMS sends ReserveNow (CSMS→CS) with id (reservation ID), expiryDateTime, idToken, and optionally evseId and/or connectorType.
2. CS responds with ReserveNowResponse:
3. Accepted — reservation created.
4. Occupied — EVSE is currently in use.
5. Faulted — EVSE has a fault.
6. Unavailable — EVSE is set to inoperative.
7. Rejected — other reason (e.g., reservations not supported).
8. If Accepted, CS sends StatusNotification with connectorStatus: Reserved for the reserved EVSE.
9. If evseId is omitted but connectorType is provided, CS picks an EVSE with a matching connector.
10. If groupIdToken is provided in ReserveNow, any token in that group can use the reservation.

#1.2 Using a Reservation (Reservation → Transaction)

1. User arrives and presents token at the reserved EVSE.
2. CS sends Authorize → CSMS responds Accepted.
3. CS matches the idToken (or groupIdToken) to the active reservation.
4. User plugs in cable.
5. CS sends TransactionEvent(Started) with reservationId field set to the reservation id. This links the transaction to the reservation.
6. Reservation is consumed — connector status transitions from Reserved to Occupied.
7. Transaction proceeds normally (see Core Flows §3).

#1.3 Reservation Expiry

If the user doesn't arrive before expiryDateTime:

1. CS sends ReservationStatusUpdate (CS→CSMS) with reservationId and reservationUpdateStatus: Expired.
2. CS sends StatusNotification with connectorStatus: Available.

ReservationUpdateStatusEnumType values: Expired, Removed.

#1.4 Reservation Cancellation

1. CSMS sends CancelReservation (CSMS→CS) with reservationId.
2. CS responds Accepted or Rejected (CancelReservationStatusEnumType).
3. If Accepted, CS sends StatusNotification with connectorStatus: Available.

#1.5 Reservation Configuration

#2. Offline Queueing and Replay

When the WebSocket connection to the CSMS is lost, the CS continues operating and queues messages for delivery upon reconnection.

#2.1 Offline Behavior Rules

What the CS does when disconnected:

• Continues charging active transactions (does not stop them).
• Authorizes new tokens using local resources (see §2.2).
• Queues all TransactionEvent messages locally with offline: true.
• Preserves seqNo ordering — numbers continue incrementing as if online.
• May also queue StatusNotification, FirmwareStatusNotification, and other CS→CSMS messages.

What happens upon reconnection:

1. CS re-establishes WebSocket connection (with backoff — see §2.3).
2. CS sends BootNotification → must get Accepted before anything else.
3. CS sends StatusNotification per connector (current state).
4. CS replays queued messages in original order, one at a time (standard single-outstanding-CALL rule).
5. Each queued TransactionEvent has offline: true so the CSMS knows it occurred during disconnection.
6. CSMS uses seqNo to detect gaps — if seqNo jumps (e.g., 3 → 6), the CSMS knows events 4 and 5 were lost.

ESCALATE: SPEC-SILENT — What happens when the CSMS rejects a replayed TransactionEvent? (e.g., CSMS lost its data and doesn't recognize the transactionId). The spec defines replay order but not error recovery.
An AI agent MUST NOT choose error recovery behavior without asking the developer:
1. Drop the rejected event and continue replaying remaining queued events
2. Stop replay and alert the operator immediately (safest, but blocks other queued events)
3. Re-queue the rejected event and retry later with backoff (risk of infinite loop if CSMS won't accept)

#2.2 Offline Authorization Decision Logic

if AuthCacheCtrlr.Enabled AND token in cache AND not expired:
    → use cached status
elif AuthCtrlr.LocalAuthorizeOffline AND token in local list:
    → use local list status
elif AuthCtrlr.OfflineTxForUnknownIdEnabled:
    → accept (allow unknown tokens offline)
else:
    → reject

#2.3 Reconnection Backoff

To prevent thundering herd when a CSMS restarts:

wait_time = RetryBackOffWaitMinimum + random(0, RetryBackOffRandomRange)

Repeat up to RetryBackOffRepeatTimes times.

#2.4 GetTransactionStatus (CSMS Checking for Queued Messages)

After reconnection, the CSMS can query whether the CS has queued messages:

1. CSMS sends GetTransactionStatus (CSMS→CS) with optional transactionId.
2. CS responds with:
3. messagesInQueue: true/false — whether queued messages remain for this transaction.
4. ongoingIndicator: true/false — whether the transaction is still active.

This is optional — the CSMS can also simply wait for queued events to arrive.

#3. Firmware Update

The CSMS instructs the CS to download and install new firmware. Progress is reported through FirmwareStatusNotification messages.

For field schemas: UpdateFirmware, FirmwareStatusNotification.

#3.1 Update Flow Steps

1. CSMS sends UpdateFirmware (CSMS→CS) with requestId, firmware (location URL, retrieveDateTime, optional signature/signingCertificate, optional installDateTime), and optionally retries and retryInterval.
2. CS responds with UpdateFirmwareResponse:
3. Accepted — will proceed with update.
4. Rejected — cannot update now.
5. AcceptedCanceled — accepted but a previous update was canceled.
6. InvalidCertificate / RevokedCertificate — signing cert issue.
7. CS waits until firmware.retrieveDateTime (if in the future).
8. CS sends status notifications via FirmwareStatusNotification (CS→CSMS) with requestId to correlate to the original request.

#3.2 Status Progression (Happy Path)

Downloading → Downloaded → [SignatureVerified] → Installing → Installed → [CS reboots] → BootNotification(reason: FirmwareUpdate)

SignatureVerified only appears if firmware.signature was provided. Without a signature: Downloaded → Installing directly.

#3.3 Status Progression with Errors

Download failure with retry:

Downloading → DownloadFailed → [wait retryInterval] → Downloading → Downloaded → ...

CS retries up to retries times, waiting retryInterval seconds between attempts. If retries is omitted, CS decides its own policy.

Signature verification failure:

Downloaded → InvalidSignature → [may retry download]

Installation failure:

Installing → InstallationFailed

or:

Installing → InstallVerificationFailed

#3.4 Deferred Installation

If firmware.installDateTime is set (future time) or there are active transactions:

Downloaded → InstallScheduled → [wait for installDateTime AND no active transactions] → Installing → Installed

The CS should not interrupt active transactions to install firmware.

ESCALATE: POLICY-DEPENDENT — "Should not interrupt" active transactions is a soft recommendation. The concrete strategy is a policy decision.
An AI agent MUST NOT choose firmware installation timing without asking the developer:
1. Wait indefinitely for all transactions to end (safest, but may never install if station is always busy)
2. Wait up to N hours then force-install, interrupting remaining transactions (set N based on site policy)
3. Schedule installation for a maintenance window (e.g., 2 AM) regardless of transaction state

#3.5 FirmwareStatusEnumType — Complete Reference

UpdateFirmwareStatusEnumType (initial response): Accepted, Rejected, AcceptedCanceled, InvalidCertificate, RevokedCertificate.

#3.6 After Reboot

After firmware installation and reboot, the CS sends BootNotification with reason: FirmwareUpdate. The CSMS can then verify the new firmware version from the chargingStation fields.

#4. GetBaseReport → NotifyReport Pagination

When the CSMS requests a device model report, the CS sends it in paginated NotifyReport messages using the seqNo / tbc pattern.

For field schemas: GetBaseReport, NotifyReport.

#4.1 Flow Steps

1. CSMS sends GetBaseReport (CSMS→CS) with requestId (integer) and reportBase (what to report).
2. CS responds with GetBaseReportResponse — status: Accepted or Rejected/NotSupported/EmptyResultSet.
3. CS sends one or more NotifyReport (CS→CSMS) messages, each containing:
4. requestId — must match the original request exactly.
5. seqNo — starts at 0, increments by 1 per message.
6. tbc — "to be continued": true if more messages follow, false (or omitted, default false) if this is the last one.
7. generatedAt — timestamp of report generation.
8. reportData — array of Component/Variable entries with attributes.
9. CSMS responds to each NotifyReport with NotifyReportResponse (empty, no required fields).
10. Report is complete when a NotifyReport arrives with tbc: false (or tbc omitted).

ReportBaseEnumType values:

#4.2 Same Pagination Pattern in Other Messages

The requestId + seqNo + tbc pattern is reused across the protocol:

When implementing any of these, the same CSMS-side logic applies: correlate by requestId, order by seqNo, collect until tbc: false.

#5. Diagnostics and Logging

#5.1 Log Upload Flow

1. CSMS sends GetLog (CSMS→CS) with logType (DiagnosticsLog or SecurityLog), requestId, and log object (containing remoteLocation URL, optional timestamp filters).
2. CS responds Accepted, Rejected, AcceptedCanceled.
3. CS sends LogStatusNotification (CS→CSMS) with status: Uploading and requestId.
4. CS uploads log file to log.remoteLocation (typically HTTP PUT or FTP).
5. CS sends LogStatusNotification with status: Uploaded (or UploadFailure).

LogStatusNotification states: BadMessage, Idle, NotSupportedOperation, PermissionDenied, Uploaded, UploadFailure, Uploading, AcceptedCanceled.

For field schemas: GetLog.

#Related Documents