OCPP 2.0.1 Deep-Dive: Sessions, Smart Charging, Certificates

OCPP 2.0.1 is the operating contract between charge points and the back-end systems that run them. Most introductions stop at “it’s the protocol.” The actual implementation is where the work is — and where small mistakes turn into ugly support patterns at scale.

This is the deeper view: session lifecycle, smart charging profiles, certificate management, and the specific gotchas that bite production deployments.

Session lifecycle in detail

A charging session has more states than the casual reading suggests. From the charge point’s view:

1. Available — connector idle, no vehicle plugged in
2. Preparing — vehicle plugged in but no authorisation yet (waiting for RFID, app, or Plug & Charge)
3. Authorized — authorisation received but charging not yet started
4. Charging — power flowing, meter values reporting
5. Suspended (EV or EVSE) — paused by either side; common during smart-charging schedules
6. Finishing — vehicle’s request to stop has been accepted; final meter values being captured
7. Faulted — error condition

State transitions are reported via StatusNotification. Each transition produces a record on the back-end side. Missing transitions — common with flaky cellular links — leave sessions in indeterminate states.

The implementation rule: the back-end is the source of truth for what state a session should be in; the charge point is the source of truth for what state it is actually in. Reconciliation runs continuously, not at month-end.

Transaction handling — the part most teams underestimate

OCPP 2.0.1 introduced explicit transaction events (TransactionEvent with eventType of Started, Updated, Ended). This replaced the messier OCPP 1.6 StartTransaction / StopTransaction / MeterValues triplet.

Three things to get right:

1. Idempotency

Charge points retry messages on network failure. The back-end must dedupe via (chargingStationId, transactionId) keys. A naive implementation that processes every message creates duplicate billable transactions. Customers notice; refunds are issued; trust erodes.

2. Out-of-order delivery

Messages can arrive late. A TransactionEvent with eventType: Updated may arrive after eventType: Ended. The back-end must treat the transaction as a state machine, not an append-only log.

3. Reconnect recovery

When a charge point reconnects after an outage, it sends a BootNotification. If transactions were active when the outage started, the charge point reports them in the boot sequence. The back-end has to recognise these as continuations of existing transactions, not new ones.

Skipping any of these creates a percentage of transactions that look wrong. At fleet scale, that percentage drives support load.

Smart charging — what 2.0.1 actually enables

Smart charging in OCPP 2.0.1 is implemented through ChargingProfile resources. A profile specifies, for a charge point or transaction, the maximum power or current allowed over time periods.

Profile kinds:

• ChargePointMaxProfile — fleet-wide limit on a charge point
• TxDefaultProfile — default applied to any new transaction
• TxProfile — per-transaction profile

Profile stack levels resolve conflicts: TxProfile beats TxDefaultProfile beats ChargePointMaxProfile.

Common applications:

• Demand response — utility issues a load-shedding signal; CPO pushes ChargePointMaxProfile lowering the limit for the affected charge points
• Solar matching — green-energy provider sets profiles tracking PV production
• Workplace fleet scheduling — each transaction assigned a profile based on departure time, vehicle SoC, and total fleet draw
• Grid-friendly residential charging — charge points throttle during peak hours, accelerate during off-peak

Smart charging is the killer feature of 2.0.1 over 1.6 for serious operators. If you’re picking the protocol version today and have any utility-grid, time-of-use, or solar-matching ambition, 2.0.1 is the only sensible answer.

ISO 15118 + Plug & Charge

ISO 15118 is the protocol between vehicle and charge point that enables Plug & Charge: insert plug, walk away, no app, no RFID, the system bills the right account.

OCPP 2.0.1 carries the relevant ISO 15118 messages between the charge point and the back-end. Specifically:

• Authorize request with idToken.type: eMAID (the certificate-based ID that ISO 15118 issues)
• CertificateSigningRequest and CertificateSigned for vehicle-side certificate provisioning
• InstallCertificate and DeleteCertificate for back-end management of trusted CAs

The certificate management is where most teams stumble. ISO 15118 uses a hierarchical PKI with multiple roots (V2G Root CAs in the EU) and frequent re-signing. CPOs need a working PKI integration; the days of “we’ll figure that out later” are over.

For broader EV charging context see our earlier EV charging OCPP post.

Certificate management for OCPP itself

Distinct from ISO 15118, OCPP 2.0.1 also has its own certificate machinery for charge-point-to-CSMS auth:

• Manufacturer certificate — burned at factory, used for first contact
• Operator certificate — issued by CPO, used for ongoing operation
• Charge point certificate signing flow — CSR via SignCertificate, response via CertificateSigned

The lifecycle:

1. Charge point ships with manufacturer cert
2. On first registration, CPO issues operator cert via signing flow
3. Operator cert rotates on a defined schedule (typically annually)
4. Revocation via DeleteCertificate for compromised certs

In production this is automated. Manual cert handling at fleet scale is impossible.

Diagnostic and update flows

Two often-overlooked features:

Diagnostic logs: the CSMS can request a charge point upload diagnostic logs via GetLog. The charge point uploads a log archive to a URL the CSMS provides. Useful for incident triage; required by some operator contracts.

Firmware update: UpdateFirmware request includes a URL. The charge point downloads and applies. Reports progress via FirmwareStatusNotification. Implementations vary widely in robustness; test rollback paths thoroughly.

For broader OTA patterns see our OTA post.

What kills OCPP deployments at scale

Three failure modes to plan for:

1. Message storms during reconnect. After a long outage, hundreds of charge points reconnect at once and dump backlogged messages. The CSMS must handle the spike. Solutions: connection rate-limiting, queue-based processing, idempotency to dedupe.

2. Cellular flakiness. Charge points on cellular links lose connection frequently. Without robust session-recovery logic, transactions drift between states. Solutions: aggressive idempotency, watchdog timers, periodic state reconciliation.

3. Vendor-specific OCPP variations. Two charge points both claiming OCPP 2.0.1 will behave differently in subtle ways. Vendor abstraction layer in the CSMS is the right defence; trying to handle vendor variance at the application level is a maintenance trap.

What we typically deliver

For a CPO platform engagement on OCPP 2.0.1:

• Vendor-abstracted OCPP handler with per-vendor adapters
• Session state machine with idempotency and reconciliation
• Smart charging profile engine with utility-signal integration
• ISO 15118 PKI integration (if Plug & Charge is in scope)
• Certificate management automation
• Diagnostic timeline per session for support
• Operational runbook covering message storms, vendor quirks, and incident response

If you are building or scaling an EV charging platform on OCPP 2.0.1, we have shipped this combination across multiple operators.