Firmware Management — Migration Guide

High-Level Overview

2.1 FirmwareType.location — Max Length Increased (512 → 2000)

Affected messages: UpdateFirmwareRequest (L01, L02)

2.2 PublishFirmwareRequest.location — Max Length Increased (512 → 2000)

Affected messages: PublishFirmwareRequest (L03)

2.3 PublishFirmwareStatusNotificationRequest.location Items — Max Length Increased

Affected messages: PublishFirmwareStatusNotificationRequest (L03)

2.4 customData Field Added to All Messages

OCPP 2.1 introduces an optional customData field (type CustomDataType) on every request, response, and nested object in this section.

Affected messages/types:

{
  "vendorId": "com.example"
}

2.5 statusInfo Added to FirmwareStatusNotificationRequest

In OCPP 2.0.1, FirmwareStatusNotificationRequest only contained status and requestId. OCPP 2.1 adds an optional statusInfo field with reasonCode and additionalInfo, allowing Charging Stations to provide richer context about status transitions.

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

2.6 JSON Schema IDs Introduced

OCPP 2.1 assigns formal URN-based JSON Schema IDs to all messages. These were not present in OCPP 2.0.1.

2.7 retries Field Constraint Formalized

OCPP 2.0.1 requirement L01.FR.09 stated firmware should be "digitally protected" without specifying exact algorithms. OCPP 2.1 explicitly names the acceptable algorithms: RSA-PSS or ECSchnorr with SHA256.

4.1 New Requirement L01.FR.32 — Reboot-to-Activate Behavior

OCPP 2.1 adds requirement L01.FR.32 which formalizes two acceptable patterns for reboot-to-activate:

4.2 Cancellation Rejection Clarified (L01.FR.27 / L02.FR.18)

OCPP 2.1 explicitly documents that a Charging Station MAY respond with Rejected to a new UpdateFirmwareRequest if it cannot cancel an ongoing update (e.g., already mid-install).

OCPP 2.1 adds a dedicated section for configuration variables relevant to firmware management. While these variables existed in 2.0.1, they are now explicitly linked to firmware management behavior.

OCPP 2.1 provides more detailed guidance on edge cases. While the underlying behavior is largely unchanged from 2.0.1, the following are now explicitly documented.

The following aspects remain identical between OCPP 2.0.1 and 2.1:

Database

Schema Validation

Firmware Signing

State Machine

Pre-Update Checks

Monitoring & Security