OCPP 2.1 Edition 2 Section L

Firmware Management — CSMS Developer Guide

Based on OCPP 2.1 Edition 2 Specification (Part 2), Section L (Firmware Management). This guide covers all firmware management flows (L01–L04), including secure and non-secure firmware updates, firmware publishing via Local Controllers, status tracking, and error handling from the CSMS perspective using OCPP-J (JSON over WebSocket).

9 Sections

4 Use Cases

L01 – L04

1. Overview

Introduction

The Firmware Management functional block enables a CSO (Charge Station Operator) to update the firmware of Charging Stations. The CSMS is responsible for initiating firmware updates, receiving and processing status notifications as the Charging Station progresses through download, verification, and installation stages, and managing firmware distribution via Local Controllers.

Initiate Updates

Send UpdateFirmwareRequest to Charging Stations to trigger firmware downloads and installations.

Track Status

Receive and process FirmwareStatusNotificationRequest messages as the CS progresses through each stage.

Manage Distribution

Use PublishFirmwareRequest / UnpublishFirmwareRequest via Local Controllers.

Actors

Actor	Role
CSMS	Initiates firmware updates, receives status notifications, manages firmware publishing on Local Controllers
Charging Station	Downloads, verifies, installs firmware; reports status back to CSMS
Local Controller	(Optional) Downloads and re-publishes firmware for local Charging Stations to save WAN bandwidth

Messages Summary

Message	Direction	Initiator
`UpdateFirmwareRequest`	CSMS → Charging Station	CSMS
`UpdateFirmwareResponse`	Charging Station → CSMS	Charging Station
`FirmwareStatusNotificationRequest`	Charging Station → CSMS	Charging Station
`FirmwareStatusNotificationResponse`	CSMS → Charging Station	CSMS
`PublishFirmwareRequest`	CSMS → Local Controller	CSMS
`PublishFirmwareResponse`	Local Controller → CSMS	Local Controller
`PublishFirmwareStatusNotificationRequest`	Local Controller → CSMS	Local Controller
`PublishFirmwareStatusNotificationResponse`	CSMS → Local Controller	CSMS
`UnpublishFirmwareRequest`	CSMS → Local Controller	CSMS
`UnpublishFirmwareResponse`	Local Controller → CSMS	Local Controller

2. Messages Reference

Reference

2.1 UpdateFirmwareRequest

Direction: CSMS → Charging Station

The CSMS sends this message to instruct a Charging Station to download and install new firmware.

UpdateFirmwareRequest Payload

{
  "requestId": 123,
  "firmware": {
    "location": "https://firmware.example.com/fw-v2.1.0.bin",
    "retrieveDateTime": "2025-12-10T10:00:00Z",
    "installDateTime": "2025-12-10T12:00:00Z",
    "signingCertificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
    "signature": "base64-encoded-signature"
  },
  "retries": 3,
  "retryInterval": 300
}

Field Reference

Field	Type	Required	Description
`requestId`	integer	Yes	Unique ID for this firmware update request. All subsequent FirmwareStatusNotificationRequest messages reference this ID.
`firmware`	FirmwareType	Yes	Object containing firmware details (see below).
`retries`	integer	No	Number of download retry attempts. 0 = no retries. If absent, the CS decides.
`retryInterval`	integer	No	Seconds between retry attempts. If absent, the CS decides.
`customData`	CustomDataType	No	Vendor-specific extension data.

FirmwareType Object

Field	Type	Required	Description
`location`	string	Yes	URI pointing to the firmware file (maxLength: 2000). Must use a protocol supported by the CS.
`retrieveDateTime`	date-time	Yes	Earliest time the CS should begin downloading (ISO 8601).
`installDateTime`	date-time	No	Scheduled installation time. If absent, install as soon as download + verification complete.
`signingCertificate`	string	No	PEM-encoded X.509 Firmware Signing Certificate (maxLength: 5500). Required for Secure Firmware Update (L01).
`signature`	string	No	Base64-encoded digital signature of the firmware file (maxLength: 800). Required for Secure Firmware Update (L01).
`customData`	CustomDataType	No	Vendor-specific extension data.

CSMS Implementation Notes

Generate a unique requestId per firmware update operation. Track this ID internally to correlate all subsequent status notifications.
For Secure updates (L01): you SHALL include signingCertificate and signature. The signature is computed using RSA-PSS or ECSchnorr over the entire firmware file, with SHA256 for hash values.
For Non-Secure updates (L02): omit signingCertificate and signature.
The location URI should use a secure protocol (HTTPS, SFTP, FTPS) — this is RECOMMENDED.
If the CS is currently installing or about to install firmware from a previous request, it SHOULD cancel the previous update and respond with AcceptedCanceled.

2.2 UpdateFirmwareResponse

Direction: Charging Station → CSMS

Received by the CSMS as the synchronous response to UpdateFirmwareRequest.

UpdateFirmwareResponse Payload

{
  "status": "Accepted",
  "statusInfo": {
    "reasonCode": "NoError",
    "additionalInfo": "Firmware update scheduled"
  }
}

UpdateFirmwareStatusEnumType Values

Value	Meaning	CSMS Action
`Accepted`	CS accepted the firmware update request.	Store the request, begin tracking firmware status via FirmwareStatusNotificationRequest.
`Rejected`	CS rejected the request.	Log rejection. Investigate reason via statusInfo. Retry or alert operator.
`AcceptedCanceled`	CS accepted the new request AND canceled a previous in-progress firmware update.	Mark previous firmware update as canceled, begin tracking new one.
`InvalidCertificate`	The provided signing certificate is invalid or could not be verified.	Log error. Verify the signing certificate is correct and re-issue.
`RevokedCertificate`	The provided signing certificate has been revoked.	Log error. Obtain and use a new, valid signing certificate.

CSMS Handling Logic

ON receive UpdateFirmwareResponse:
  SWITCH response.status:
    CASE "Accepted":
      → Mark firmware update as "in progress" in your tracking system
      → Expect FirmwareStatusNotificationRequest messages with this requestId

    CASE "AcceptedCanceled":
      → Mark PREVIOUS firmware update as "canceled"
      → Mark NEW firmware update as "in progress"
      → May receive DownloadFailed/InstallationFailed for the old update

    CASE "Rejected":
      → Mark firmware update as "rejected"
      → Log statusInfo.reasonCode and statusInfo.additionalInfo
      → Alert operator or retry later

    CASE "InvalidCertificate":
      → Mark firmware update as "failed - invalid certificate"
      → Check and re-issue with correct signing certificate

    CASE "RevokedCertificate":
      → Mark firmware update as "failed - revoked certificate"
      → Obtain new certificate and re-issue

2.3 FirmwareStatusNotificationRequest

Direction: Charging Station → CSMS

The Charging Station sends this message to the CSMS each time it enters a new state in the firmware update process.

FirmwareStatusNotificationRequest Payload

{
  "status": "Downloading",
  "requestId": 123,
  "statusInfo": {
    "reasonCode": "InProgress",
    "additionalInfo": "Download at 45%"
  }
}

FirmwareStatusEnumType Values

Value	Description	CSMS Handling
`Idle`	No firmware update in progress.	No action required. Confirms no active update.
`DownloadScheduled`	CS has not started downloading yet (busy charging, or retrieveDateTime is in the future).	Log. Download will start later.
`Downloading`	CS is actively downloading the firmware file.	Log. Download is in progress.
`DownloadPaused`	Download was temporarily paused (e.g. CS has higher-priority tasks).	Log. Monitor — the download should resume.
`Downloaded`	Firmware file has been successfully downloaded.	Log. Next step: verification (secure) or installation (non-secure).
`DownloadFailed`	Download failed after all retry attempts.	ALERT operator. Firmware update has failed. Consider re-initiating.
`SignatureVerified`	(Secure only) Firmware digital signature verified successfully.	Log. Next step: installation.
`InvalidSignature`	(Secure only) Firmware signature verification failed.	ALERT operator. Firmware file or signature is corrupted/wrong.
`InstallScheduled`	Installation scheduled for a future installDateTime, or CS is waiting for transactions to finish.	Log. Installation will begin at the scheduled time.
`InstallRebooting`	CS is about to reboot (before installing, or after installing to activate).	Log. Expect WebSocket connection to drop and reconnect.
`Installing`	CS is installing the firmware.	Log. Installation in progress. Note: may be omitted if bootloader cannot send OCPP messages.
`InstallVerificationFailed`	Post-installation verification failed (e.g. checksum mismatch).	ALERT operator. CS may need manual intervention.
`Installed`	Firmware successfully installed and activated.	Mark firmware update as complete/successful.
`InstallationFailed`	Firmware installation failed.	ALERT operator. Investigate logs. Consider re-initiating.

Response: The CSMS always responds with FirmwareStatusNotificationResponse which is an empty object {} (no required fields).

CSMS Handling Logic

ON receive FirmwareStatusNotificationRequest:
  1. Validate the message against the JSON schema
  2. Extract requestId and match to a tracked firmware update
  3. Log the status transition with timestamp

  SWITCH request.status:
    CASE "Idle":
      → No active firmware update. Informational only.

    CASE "DownloadScheduled":
      → Update internal state to "download_scheduled"

    CASE "Downloading":
      → Update internal state to "downloading"

    CASE "DownloadPaused":
      → Update internal state to "download_paused"
      → Monitor for resumption

    CASE "Downloaded":
      → Update internal state to "downloaded"

    CASE "DownloadFailed":
      → Update internal state to "download_failed"
      → ALERT: Firmware download failed. Operator action needed.

    CASE "SignatureVerified":
      → Update internal state to "signature_verified"
      → (Secure update only)

    CASE "InvalidSignature":
      → Update internal state to "invalid_signature"
      → ALERT: Signature verification failed.

    CASE "InstallScheduled":
      → Update internal state to "install_scheduled"

    CASE "InstallRebooting":
      → Update internal state to "install_rebooting"
      → Expect WebSocket disconnect and reconnect

    CASE "Installing":
      → Update internal state to "installing"

    CASE "InstallVerificationFailed":
      → Update internal state to "install_verification_failed"
      → ALERT: Post-install verification failed.

    CASE "Installed":
      → Update internal state to "installed" / "complete"
      → Mark firmware update as successful

    CASE "InstallationFailed":
      → Update internal state to "installation_failed"
      → ALERT: Installation failed. Operator action needed.

  4. Respond with FirmwareStatusNotificationResponse: {}

2.4 PublishFirmwareRequest

Direction: CSMS → Local Controller

The CSMS sends this to instruct a Local Controller to download firmware and publish it for local Charging Stations.

PublishFirmwareRequest Payload

{
  "location": "https://firmware.example.com/fw-v2.1.0.bin",
  "checksum": "d41d8cd98f00b204e9800998ecf8427e",
  "requestId": 456,
  "retries": 3,
  "retryInterval": 600
}

Field Reference

Field	Type	Required	Description
`location`	string	Yes	URI pointing to the firmware file to download and publish (maxLength: 2000).
`checksum`	string	Yes	MD5 checksum (hex, 32 chars) over the entire firmware file. See RFC-1321.
`requestId`	integer	Yes	Unique request identifier. Referenced in subsequent PublishFirmwareStatusNotificationRequest messages.
`retries`	integer	No	Download retry attempts. 0 = no retries.
`retryInterval`	integer	No	Seconds between retry attempts.
`customData`	CustomDataType	No	Vendor-specific extension data.

CSMS Implementation Notes

The MD5 checksum SHALL be calculated over the entire firmware file.
After the Local Controller reports Published status, the CSMS can send UpdateFirmwareRequest to connected Charging Stations with the location URI pointing to the Local Controller.

2.5 PublishFirmwareResponse

Direction: Local Controller → CSMS

PublishFirmwareResponse Payload

{
  "status": "Accepted"
}

CSMS Handling Logic

ON receive PublishFirmwareResponse:
  IF status == "Accepted":
    → Track the publish operation using requestId
    → Await PublishFirmwareStatusNotificationRequest messages

  IF status == "Rejected":
    → Log rejection with statusInfo details
    → Alert operator

2.6 PublishFirmwareStatusNotificationRequest

Direction: Local Controller → CSMS

The Local Controller sends this to report progress of the firmware publish process.

PublishFirmwareStatusNotificationRequest — Published (success)

{
  "status": "Published",
  "location": [
    "https://local-controller.local/firmware/fw-v2.1.0.bin",
    "http://local-controller.local/firmware/fw-v2.1.0.bin",
    "ftp://local-controller.local/firmware/fw-v2.1.0.bin"
  ],
  "requestId": 456
}

PublishFirmwareStatusEnumType Values

Value	Description	CSMS Action
`Idle`	No publish operation in progress.	Informational only.
`DownloadScheduled`	Download is scheduled.	Log. Waiting for download to start.
`Downloading`	Local Controller is downloading the firmware.	Log. Download in progress.
`Downloaded`	Firmware successfully downloaded by Local Controller.	Log. Next step: checksum verification.
`DownloadFailed`	Download failed.	ALERT operator. Re-issue PublishFirmwareRequest if appropriate.
`DownloadPaused`	Download temporarily paused.	Log. Monitor for resumption.
`ChecksumVerified`	MD5 checksum verified successfully.	Log. Next step: publish.
`InvalidChecksum`	MD5 checksum verification failed.	ALERT operator. Firmware file is corrupted or checksum was wrong.
`Published`	Firmware is published and available at the reported location URIs.	Store the location URIs. Send UpdateFirmwareRequest to Charging Stations pointing to these URIs.
`PublishFailed`	Publishing the firmware file failed.	ALERT operator. Investigate Local Controller logs.

Response: The CSMS always responds with PublishFirmwareStatusNotificationResponse: an empty object {}.

CSMS Handling Logic

ON receive PublishFirmwareStatusNotificationRequest:
  1. Validate the message
  2. Match requestId to a tracked publish operation

  SWITCH request.status:
    CASE "Published":
      → Store the location[] URIs
      → Mark publish operation as complete
      → Now send UpdateFirmwareRequest to target Charging Stations
        using one of the Local Controller URIs as firmware.location

    CASE "DownloadFailed":
      → Mark publish operation as failed
      → ALERT operator

    CASE "InvalidChecksum":
      → Mark publish operation as failed
      → ALERT: checksum mismatch — verify firmware file integrity

    CASE "PublishFailed":
      → Mark publish operation as failed
      → ALERT operator

    CASE others (Downloading, Downloaded, ChecksumVerified, etc.):
      → Log status transition, update internal tracking state

  3. Respond with PublishFirmwareStatusNotificationResponse: {}

2.7 UnpublishFirmwareRequest

Direction: CSMS → Local Controller

The CSMS sends this to instruct a Local Controller to stop serving a published firmware file.

UnpublishFirmwareRequest Payload

{
  "checksum": "d41d8cd98f00b204e9800998ecf8427e"
}

Field Reference

Field	Type	Required	Description
`checksum`	string	Yes	MD5 checksum of the firmware file to unpublish (maxLength: 32). Acts as a unique identifier.
`customData`	CustomDataType	No	Vendor-specific extension data.

Note: The CSMS uses the MD5 checksum as the unique identifier. Only send this after a firmware has been successfully published (status Published received).

2.8 UnpublishFirmwareResponse

Direction: Local Controller → CSMS

UnpublishFirmwareResponse Payload

{
  "status": "Unpublished"
}

UnpublishFirmwareStatusEnumType Values

Value	Description	CSMS Action
`Unpublished`	Firmware successfully unpublished.	Mark firmware as unpublished. The Local Controller is no longer serving this file.
`NoFirmware`	No published firmware file matching the checksum was found.	Log warning. The firmware was already unpublished or never published with this checksum.
`DownloadOngoing`	A CS is currently downloading the firmware from the Local Controller. Firmware was NOT unpublished.	Retry later. The LC refuses to unpublish while an active download is in progress.

CSMS Handling Logic

ON receive UnpublishFirmwareResponse:
  SWITCH response.status:
    CASE "Unpublished":
      → Mark firmware as unpublished in tracking system
      → Remove stored Local Controller URIs for this firmware

    CASE "NoFirmware":
      → Log: firmware was not found / already unpublished
      → Update tracking state accordingly

    CASE "DownloadOngoing":
      → Log: cannot unpublish, active download in progress
      → Schedule a retry after a reasonable delay
      → Or alert operator to decide

3. L01 — Secure Firmware Update

CSMS-Initiated

Use Case ID	L01
Direction	CSMS → CS (CSMS initiates)
Objective	Download and install a firmware update with cryptographic signature verification
Prerequisite	The Charging Station manufacturer has provided a firmware update with a digital signature
OCPP Messages	UpdateFirmwareRequest / UpdateFirmwareResponse, FirmwareStatusNotificationRequest / FirmwareStatusNotificationResponse

Sequence Diagram (Happy Path)

Sequence Diagram (CSMS perspective)

CSMS                                          Charging Station
  │                                                │
  │──── UpdateFirmwareRequest(requestId=123) ─────>│
  │     (with signingCertificate + signature)       │
  │<──── UpdateFirmwareResponse(Accepted) ─────────│
  │                                                │
  │           [CS verifies certificate]            │
  │           [Waits for retrieveDateTime]         │
  │                                                │
  │<── FirmwareStatusNotification(Downloading) ────│
  │──── FirmwareStatusNotificationResponse() ─────>│
  │                                                │
  │           [CS downloads firmware]              │
  │                                                │
  │<── FirmwareStatusNotification(Downloaded) ─────│
  │──── FirmwareStatusNotificationResponse() ─────>│
  │                                                │
  │           [CS verifies signature]              │
  │                                                │
  │<── FirmwareStatusNotification(SignatureVerified)│
  │──── FirmwareStatusNotificationResponse() ─────>│
  │                                                │
  │         [Waits for transactions to end]        │
  │                                                │
  │  ┌─[opt: if reboot required before install]────┐
  │  │                                             │
  │<─│─ FirmwareStatusNotification(InstallRebooting)│
  │──│─ FirmwareStatusNotificationResponse() ─────>│
  │  │        [CS reboots, reconnects]             │
  │  └─────────────────────────────────────────────┘
  │                                                │
  │<── FirmwareStatusNotification(Installing) ─────│
  │──── FirmwareStatusNotificationResponse() ─────>│
  │                                                │
  │           [CS installs firmware]               │
  │                                                │
  │  ┌─[opt: if reboot required to activate]───────┐
  │  │                                             │
  │<─│─ FirmwareStatusNotification(InstallRebooting)│
  │──│─ FirmwareStatusNotificationResponse() ─────>│
  │  │        [CS reboots, reconnects]             │
  │  └─────────────────────────────────────────────┘
  │                                                │
  │<── FirmwareStatusNotification(Installed) ──────│
  │──── FirmwareStatusNotificationResponse() ─────>│
  │                                                │
  │          [Firmware update complete]            │

CSMS Step-by-Step Implementation

Step 1: Initiate the Firmware Update

Send UpdateFirmwareRequest with signing certificate and signature included.

UpdateFirmwareRequest — Secure (L01)

{
  "requestId": 123,
  "firmware": {
    "location": "https://firmware-server.example.com/firmware/cs-model-x/v2.1.0.signed.bin",
    "retrieveDateTime": "2025-12-10T10:00:00Z",
    "installDateTime": "2025-12-10T12:00:00Z",
    "signingCertificate": "-----BEGIN CERTIFICATE-----\nMIIB...(PEM-encoded X.509)...\n-----END CERTIFICATE-----",
    "signature": "MEUCIQD...base64-encoded-signature..."
  },
  "retries": 3,
  "retryInterval": 300
}

Requirements

signingCertificate SHALL be included for security purposes (L01.FR.11).
The signature is calculated over the entire firmware file using RSA-PSS or ECSchnorr with SHA256 (L01.FR.04, L01.FR.09).
The manufacturer SHALL NOT use intermediate certificates for the firmware signing certificate.

Step 2: Handle UpdateFirmwareResponse

Response Status	Action
`Accepted`	Begin tracking. Expect FirmwareStatusNotificationRequest messages.
`Rejected`	Log failure. Retry later or investigate.
`AcceptedCanceled`	Previous update canceled, new one accepted. Track the new update.
`InvalidCertificate`	Certificate validation failed on the CS side. Fix certificate and re-send.
`RevokedCertificate`	Certificate was revoked. Obtain new certificate.

Step 3: Process FirmwareStatusNotificationRequest Messages

Validate that requestId matches the active firmware update.
Log the status transition.
Update your internal firmware update tracking state.
Respond with FirmwareStatusNotificationResponse: {}.

Expected Happy Path Status Sequence (Secure)

DownloadScheduled (optional) → Downloading → Downloaded → SignatureVerified
  → InstallScheduled (optional) → InstallRebooting (optional) → Installing
  → InstallRebooting (optional) → Installed

Terminal Failure States

No further notifications expected after these statuses:

DownloadFailed — all retry attempts exhausted
InvalidSignature — signature verification failed (also triggers SecurityEventNotificationRequest with event InvalidFirmwareSignature)
InstallVerificationFailed — post-install verification failed
InstallationFailed — installation failed

Step 4: Handle WebSocket Disconnects During Reboots

When you receive InstallRebooting:

Expect the WebSocket connection to drop.
Do NOT mark the Charging Station as offline/failed.
Wait for the Charging Station to reconnect.
Upon reconnect, expect a BootNotificationRequest followed by continued FirmwareStatusNotificationRequest messages.

Step 5: Confirm Completion

When status = Installed is received: mark the firmware update as successfully completed. The Charging Station should now be running the new firmware version and SHOULD have already activated it.

Failure Scenarios

Failure	Status Received	Additional Messages	CSMS Action
Invalid certificate	`UpdateFirmwareResponse.status = InvalidCertificate`	—	Fix certificate and re-send
Certificate invalid (async)	`UpdateFirmwareResponse(InvalidCertificate)`	SecurityEventNotification (InvalidFirmwareSigningCertificate)	Log security event
Download failed	`DownloadFailed`	—	Alert operator, consider re-initiating
Invalid signature	`InvalidSignature`	SecurityEventNotification (InvalidFirmwareSignature)	Alert operator, verify firmware/signature
Install verification failed	`InstallVerificationFailed`	—	Alert operator
Installation failed	`InstallationFailed`	—	Alert operator, consider re-initiating

Key Requirements (CSMS Perspective)

Req ID	Requirement
`L01.FR.01`	Expect a FirmwareStatusNotificationRequest for every state change.
`L01.FR.02`	If CS enters Invalid Certificate state, also expect SecurityEventNotificationRequest with InvalidFirmwareSigningCertificate.
`L01.FR.03`	If CS enters Invalid Signature state, also expect SecurityEventNotificationRequest with InvalidFirmwareSignature.
`L01.FR.10`	Every FirmwareStatusNotificationRequest SHALL contain the same requestId as the initiating UpdateFirmwareRequest.
`L01.FR.11`	CSMS SHALL include the Firmware Signing Certificate in the UpdateFirmwareRequest.
`L01.FR.20`	The requestId field is mandatory in FirmwareStatusNotificationRequest unless status = Idle.
`L01.FR.24`	If the CS is installing/about to install and receives a new UpdateFirmwareRequest, it SHOULD cancel the old update and respond AcceptedCanceled.
`L01.FR.25`	If CSMS sends TriggerMessageRequest for FirmwareStatusNotification and last status was Installed, CS returns Idle.
`L01.FR.26`	If CSMS sends TriggerMessageRequest for FirmwareStatusNotification and last status was NOT Installed, CS returns the last sent status.
`L01.FR.28`	When installation succeeds, CS sends Installed status. CS SHOULD have already activated the firmware.
`L01.FR.31`	After successful install, CS also sends SecurityEventNotificationRequest with type = FirmwareUpdated.
`L01.FR.32`	When CS needs to reboot to activate firmware: (a) preferred — send InstallRebooting then Installed from new firmware, or (b) send only Installed without rebooting notification.

4. L02 — Non-Secure Firmware Update

CSMS-Initiated

Use Case ID	L02
Direction	CSMS → CS (CSMS initiates)
Objective	Download and install a firmware update without cryptographic signature verification
Prerequisite	The Charging Station manufacturer has provided a firmware update
OCPP Messages	UpdateFirmwareRequest / UpdateFirmwareResponse, FirmwareStatusNotificationRequest / FirmwareStatusNotificationResponse

Sequence Diagram (Happy Path)

Sequence Diagram (CSMS perspective)

CSMS                                          Charging Station
  │                                                │
  │──── UpdateFirmwareRequest(requestId=456) ─────>│
  │     (NO signingCertificate / signature)        │
  │<──── UpdateFirmwareResponse(Accepted) ─────────│
  │                                                │
  │<── FirmwareStatusNotification(Downloading) ────│
  │──── FirmwareStatusNotificationResponse() ─────>│
  │                                                │
  │           [CS downloads firmware]              │
  │                                                │
  │<── FirmwareStatusNotification(Downloaded) ─────│
  │──── FirmwareStatusNotificationResponse() ─────>│
  │                                                │
  │         [Waits for transactions to end]        │
  │                                                │
  │  ┌─[opt: if reboot required before install]────┐
  │<─│─ FirmwareStatusNotification(InstallRebooting)│
  │──│─ FirmwareStatusNotificationResponse() ─────>│
  │  │        [CS reboots, reconnects]             │
  │  └─────────────────────────────────────────────┘
  │                                                │
  │<── FirmwareStatusNotification(Installing) ─────│
  │──── FirmwareStatusNotificationResponse() ─────>│
  │                                                │
  │           [CS installs firmware]               │
  │                                                │
  │  ┌─[opt: if reboot required to activate]───────┐
  │<─│─ FirmwareStatusNotification(InstallRebooting)│
  │──│─ FirmwareStatusNotificationResponse() ─────>│
  │  │        [CS reboots, reconnects]             │
  │  └─────────────────────────────────────────────┘
  │                                                │
  │<── FirmwareStatusNotification(Installed) ──────│
  │──── FirmwareStatusNotificationResponse() ─────>│
  │                                                │
  │          [Firmware update complete]            │

Differences from L01 (Secure Update)

Aspect	L01 (Secure)	L02 (Non-Secure)
signingCertificate in request	Required	Omitted
signature in request	Required	Omitted
SignatureVerified status	Expected in flow	Never sent
InvalidSignature status	Possible failure	Never sent
InvalidCertificate response	Possible	Never sent
RevokedCertificate response	Possible	Never sent
SecurityEventNotification for cert/sig	Yes	No

CSMS Step-by-Step Implementation

Step 1: Initiate the Firmware Update

Send UpdateFirmwareRequest without signingCertificate or signature fields.

UpdateFirmwareRequest — Non-Secure (L02)

{
  "requestId": 456,
  "firmware": {
    "location": "https://firmware-server.example.com/firmware/cs-model-x/v2.1.0.bin",
    "retrieveDateTime": "2025-12-10T10:00:00Z",
    "installDateTime": "2025-12-10T12:00:00Z"
  },
  "retries": 3,
  "retryInterval": 300
}

Steps 2–5: Identical to L01

Handle UpdateFirmwareResponse, process FirmwareStatusNotificationRequest messages, handle reboots, and confirm completion exactly as described in L01 — except you will never see SignatureVerified, InvalidSignature, InvalidCertificate, or RevokedCertificate.

Expected Happy Path Status Sequence (Non-Secure)

DownloadScheduled (optional) → Downloading → Downloaded
  → InstallScheduled (optional) → InstallRebooting (optional) → Installing
  → InstallRebooting (optional) → Installed

Key Requirements (CSMS Perspective)

All requirements from L01 apply except those related to certificate/signature verification.

Req ID	Note
`L02.FR.01`	Same as L01.FR.01 — expect status notifications for every state change.
`L02.FR.06`	Same as L01.FR.10 — every notification SHALL contain the same requestId.
`L02.FR.14`	Same as L01.FR.20 — requestId is mandatory unless status = Idle.
`L02.FR.15`	Same as L01.FR.24 — CS SHOULD cancel old update and respond AcceptedCanceled for new request.
`L02.FR.20`	CS SHALL send Installed when firmware is successfully installed and activated.

5. L03 — Publish Firmware on Local Controller

CSMS-Initiated

Use Case ID	L03
Direction	CSMS → Local Controller (CSMS initiates)
Objective	Instruct a Local Controller to download firmware and publish it for local Charging Stations, saving WAN bandwidth
Actors	CSMS, Local Controller
OCPP Messages	PublishFirmwareRequest / PublishFirmwareResponse, PublishFirmwareStatusNotificationRequest / PublishFirmwareStatusNotificationResponse

Sequence Diagram (Happy Path)

Sequence Diagram (CSMS perspective)

CSMS                                       Local Controller
  │                                                │
  │──── PublishFirmwareRequest(requestId=456) ─────>│
  │     (location, checksum, retries)              │
  │<──── PublishFirmwareResponse(Accepted) ────────│
  │                                                │
  │<── PublishFirmwareStatusNotification ──────────│
  │    (status=Downloading)                        │
  │──── PublishFirmwareStatusNotificationResponse()>│
  │                                                │
  │         [LC downloads firmware]                │
  │                                                │
  │<── PublishFirmwareStatusNotification ──────────│
  │    (status=Downloaded)                         │
  │──── PublishFirmwareStatusNotificationResponse()>│
  │                                                │
  │         [LC verifies MD5 checksum]             │
  │                                                │
  │<── PublishFirmwareStatusNotification ──────────│
  │    (status=ChecksumVerified)                   │
  │──── PublishFirmwareStatusNotificationResponse()>│
  │                                                │
  │         [LC publishes firmware on local URIs]   │
  │                                                │
  │<── PublishFirmwareStatusNotification ──────────│
  │    (status=Published, location=[...])          │
  │──── PublishFirmwareStatusNotificationResponse()>│
  │                                                │
  │   [CSMS now sends UpdateFirmwareRequest to     │
  │    Charging Stations using LC's local URIs]    │

CSMS Step-by-Step Implementation

Step 1: Send PublishFirmwareRequest

PublishFirmwareRequest

{
  "location": "https://firmware-server.example.com/firmware/cs-model-x/v2.1.0.bin",
  "checksum": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
  "requestId": 456,
  "retries": 3,
  "retryInterval": 600
}

Requirements

Calculate the MD5 checksum over the entire firmware file (L03.FR.02).
The checksum must be a 32-character hexadecimal string.

Step 2: Handle PublishFirmwareResponse

Response Status	Action
`Accepted`	Track the publish operation. Expect PublishFirmwareStatusNotificationRequest messages.
`Rejected`	Log failure. Investigate statusInfo.

Step 3: Process PublishFirmwareStatusNotificationRequest Messages

Validate and match requestId.
Log the status transition.
Respond with PublishFirmwareStatusNotificationResponse: {}.

Critical action on Published status: Extract the location array — these are the URIs where the firmware is now available. The Local Controller publishes using all its supported protocols (HTTP, HTTPS, FTP). Use one of these URIs as the firmware.location when sending UpdateFirmwareRequest to Charging Stations connected to this Local Controller.

Step 4: Send Firmware Updates to Charging Stations

After receiving Published status with locations, send UpdateFirmwareRequest (L01 or L02) to target Charging Stations, setting firmware.location to one of the Local Controller's URIs.

Failure Scenarios

Failure	Status Received	CSMS Action
Download failed	`DownloadFailed`	Alert operator. Re-issue PublishFirmwareRequest.
Checksum mismatch	`InvalidChecksum`	Alert operator. Verify firmware file integrity and checksum.
Publish failed	`PublishFailed`	Alert operator. Investigate Local Controller.

Key Requirements (CSMS Perspective)

Req ID	Requirement
`L03.FR.01`	Expect a PublishFirmwareStatusNotificationRequest for every state change.
`L03.FR.02`	MD5 checksum SHALL be calculated over the entire firmware file.
`L03.FR.04`	The Local Controller SHALL set URIs for all supported protocols in the location field of the Published status message.
`L03.FR.05`	Local Controller SHALL respond with a PublishFirmwareResponse indicating acceptance.
`L03.FR.09`	After successfully publishing, the LC sends Published status.
`L03.FR.10`	If CSMS sends TriggerMessageRequest for PublishFirmwareStatusNotification and last status was Published, LC returns Idle.
`L03.FR.11`	If CSMS sends TriggerMessageRequest for PublishFirmwareStatusNotification and last status was NOT Published, LC returns the last sent status.

6. L04 — Unpublish Firmware on Local Controller

CSMS-Initiated

Use Case ID	L04
Direction	CSMS → Local Controller (CSMS initiates)
Objective	Stop a Local Controller from serving a firmware update to Charging Stations
Prerequisite	A firmware has been successfully published by the Local Controller
OCPP Messages	UnpublishFirmwareRequest / UnpublishFirmwareResponse

Sequence Diagram

Sequence Diagram (CSMS perspective)

CSMS                                       Local Controller
  │                                                │
  │──── UnpublishFirmwareRequest ─────────────────>│
  │     (checksum="a1b2c3d4...")                   │
  │<──── UnpublishFirmwareResponse(Unpublished) ───│
  │                                                │

CSMS Step-by-Step Implementation

Step 1: Send UnpublishFirmwareRequest

Use the same MD5 checksum that was provided in the original PublishFirmwareRequest.

UnpublishFirmwareRequest

{
  "checksum": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4"
}

Step 2: Handle UnpublishFirmwareResponse

Response Status	Meaning	CSMS Action
`Unpublished`	Firmware successfully removed from Local Controller.	Update internal state. Do NOT send new UpdateFirmwareRequest to CS pointing to this LC's URIs.
`NoFirmware`	No firmware matching the checksum was found.	Log warning. Firmware may already have been unpublished.
`DownloadOngoing`	A CS is actively downloading from the LC. Firmware was NOT unpublished.	Retry later. Schedule a retry after a reasonable interval (e.g. 5-10 minutes).

Key Requirements (CSMS Perspective)

Req ID	Requirement
`L04.FR.01`	If no ongoing download, the firmware SHALL be unpublished.
`L04.FR.02`	After successful unpublish, LC responds with Unpublished.
`L04.FR.03`	If no published file matches the checksum, LC responds with NoFirmware.
`L04.FR.04`	If a CS is actively downloading, LC responds with DownloadOngoing and does NOT unpublish.

7. Firmware Status State Machine

Reference

The Charging Station transitions through these states during a firmware update. The CSMS must track these transitions.

State Diagram

Firmware Update State Machine

                          ┌──────────────────────────────────────────────────┐
                          │                                                  │
                          ▼                                                  │
  ●──> [Idle] ──> [DownloadScheduled] ──> [Downloading] ◄───────────────────┤
                                              │    │                         │
                                              │    │  (paused)               │
                                              │    └──> [DownloadPaused] ────┘
                                              │              (resumed)
                                              │
                                    (failed)  │  (success)
                                       │      │
                                       ▼      ▼
                              [DownloadFailed] [Downloaded]
                                                   │
                                          ┌────────┴────────┐
                                          │                 │
                                    (secure only)     (non-secure)
                                          │                 │
                                          ▼                 │
                                 [SignatureVerified]         │
                                          │                 │
                           (invalid sig)  │                 │
                                 ▼        │                 │
                          [InvalidSignature]                │
                                          │                 │
                                          ├─────────────────┘
                                          │
                            ┌─────────────┼──────────────────┐
                            │             │                  │
                   (future install)  (reboot first)   (install now)
                            │             │                  │
                            ▼             ▼                  │
                   [InstallScheduled] [InstallRebooting_1]   │
                            │             │                  │
                            └─────────────┼──────────────────┘
                                          │
                                          ▼
                                     [Installing]
                                          │
                            ┌─────────────┼──────────────┐
                            │             │              │
                     (verify fail)  (reboot needed)  (success)
                            │             │              │
                            ▼             ▼              │
               [InstallVerificationFailed] [InstallRebooting_2]
                                          │              │
                                    ┌─────┼──────────────┘
                                    │     │
                             (failed)   (success)
                                │         │
                                ▼         ▼
                      [InstallationFailed] [Installed]

Terminal States

State	Outcome
`Installed`	Success — firmware update complete
`DownloadFailed`	Failure — download failed after all retries
`InvalidSignature`	Failure — signature invalid (secure only)
`InstallVerificationFailed`	Failure — post-install verification failed
`InstallationFailed`	Failure — installation failed

8. Configuration Variables

Reference

These Charging Station configuration variables are relevant to firmware management. The CSMS can read them using GetVariablesRequest and set them using SetVariablesRequest.

Variable	Description	CSMS Relevance
`FileTransferProtocols`	Reports which file transfer protocols the Charging Station supports (e.g. HTTP, HTTPS, FTP, SFTP, FTPS).	Check before sending firmware URI. Use a supported protocol in `firmware.location`.
`AllowNewSessionsPendingFirmwareUpdate`	If `false` (or not set), the CS will set all unused EVSEs to UNAVAILABLE while waiting for transactions to end before installing firmware.	Be aware that EVSEs may become unavailable during firmware update.

9. Error Handling & Edge Cases

Reference

9.1 Canceling an In-Progress Update

To cancel an ongoing firmware update, send a new UpdateFirmwareRequest. The Charging Station:

SHOULD cancel the old update (L01.FR.24 / L02.FR.15).
Responds with AcceptedCanceled.
May send DownloadFailed or InstallationFailed for the canceled update.
If the CS cannot cancel (e.g., already mid-install), it MAY respond with Rejected (L01.FR.27 / L02.FR.18).

9.2 Requesting Firmware Status via TriggerMessage

The CSMS can request the current firmware status at any time by sending a TriggerMessageRequest with requestedMessage = FirmwareStatusNotification.

Firmware Update Status Response

Condition	CS Response
Last FirmwareStatusNotification had status = Installed	CS sends FirmwareStatusNotificationRequest with status = Idle
Last FirmwareStatusNotification had status ≠ Installed	CS sends FirmwareStatusNotificationRequest with the last sent status
No firmware update ongoing, triggered by TriggerMessageRequest	CS sends FirmwareStatusNotificationRequest with status = Idle (requestId is optional)

Publish Firmware Status Response

Condition	LC Response
Last PublishFirmwareStatusNotification had status = Published	LC sends PublishFirmwareStatusNotificationRequest with status = Idle
Last status was NOT Published	LC sends PublishFirmwareStatusNotificationRequest with the last sent status

9.3 Handling Reboots During Firmware Update

The InstallRebooting status can appear 0, 1, or 2 times during a single update:

0 times: no reboot needed
1 time: reboot before install OR reboot after install to activate
2 times: reboot before install AND reboot after install to activate

Important

The order of FirmwareStatusNotificationRequest messages and reboots is not fixed per the spec. When the Charging Station reboots, the CSMS should expect:

WebSocket disconnect
WebSocket reconnect
BootNotificationRequest
Continued FirmwareStatusNotificationRequest messages

9.4 Installing Status May Be Omitted

Per L01.FR.23: If the bootloader cannot send OCPP messages during a reboot-before-install, the Installing status may be omitted. The CSMS should not assume Installing will always be received.

9.5 EVSE Availability During Firmware Update

When AllowNewSessionsPendingFirmwareUpdate is false or unset:

The CS will set all unused EVSEs to UNAVAILABLE while waiting for transactions to finish.
Any EVSE that becomes available before installation completes will also be set to UNAVAILABLE.
The CSMS should expect StatusNotificationRequest messages marking EVSEs as Unavailable.
EVSEs will return to their normal status after the firmware update completes.

9.6 Security Events

During secure firmware updates, the CSMS may receive SecurityEventNotificationRequest messages:

Security Event Type	Trigger
`InvalidFirmwareSigningCertificate`	Certificate validation failed (L01.FR.02)
`InvalidFirmwareSignature`	Signature verification failed (L01.FR.03)
`FirmwareUpdated`	Firmware successfully installed (L01.FR.31)

The CSMS should log these security events and handle them appropriately in its security monitoring system.

9.7 Recommended Firmware Hosting

Use secure protocols (HTTPS, SFTP, FTPS) for firmware hosting — this is RECOMMENDED.
Alternatively, encrypt the firmware file itself before hosting.
FTP implementations should support Passive FTP for traversal across network topologies.
Secure the firmware when stored on a server or workstation.

9.8 Network Configuration Fallback

When migrating to a new version of OCPP, it is RECOMMENDED to install a fallback NetworkConnectionProfile with the new configuration. This ensures the Charging Station can reconnect even if the firmware update changes OCPP behavior.