OCPP 2.0.

1 Edition 2
Errata 2024-04
Table of Contents
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Terminology and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
0. Part 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Generic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Device Model: Addressing Components and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Page 6 - (2023-12) - section 4.1 Components: Clarification about tiers for EVSE/Connector components . . . . . . . . . . . 4
1.1.2. Page 10 - (2023-12) - GetBaseReport supported 'ReportBases' [350] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Page 4 - (2024-02) 2.1.4. Definition of data type AnyType [747]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Page 15 - (2024-04) 3. Generic requirements [759] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Use case A Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Page 23 - (2023-06) Requirement A00.FR.316: Make clear that InvalidTLSVersion must be queued [689] . . . . . . . . . . . 6
2.2.2. Page 31 - (2024-02) A02 - Update Charging Station Certificate by request of CSMS [744]. . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Use case B Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Page 51 - (2023-12) Requirement B03.FR.08 incorrect, and B03.FR.03 rephrased [712] . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Page 51 - (2023-12) Typo in B03.FR.06 [736] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3. Page 61 - (2023-06) Requirement B08.FR.19 and N02.FR.15 are ambiguous w.r.t. evse and instance wildcards
[676] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.4. Page 62 - (2023-06) Use case B09/B10: Extended scenario description [683]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.5. Page 65 - (2024-02) Use case B11/12: Reset of EVSE does not cause reboot of Charging Station [724]. . . . . . . . . . . . 12
2.4. Use case C Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1. Page 72 - (2024-04) C 1.4 Local Authorization List [737] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2. Page 90 - (2024-04) C07.FR.05 does not require iso15118CertificateHashData [761] . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3. Page 90 - (2023-06) C07 requirements for certificateStatus missing [680]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.4. Page 97 - (2023-06) Requirement C10.FR.06 needs to be removed [685]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.5. Page 97 - (2024-04) C10 Authorization Cache: cacheExpiryDateTime [737] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.6. Page 102 - (2023-06) Requirement C13.FR.04 enhanced [701] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.7. Page 102 - (2024-04) cacheExpiryDateTime requirements [737] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5. Use case D LocalAuthorizationList Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1. Page 111 - (2024-02) D01 - Send Local Authorization List - Requirements [745] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6. Use Case E Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.1. Page 118 - (2024-02) Clarify that TransactionEvent(Started) requires chargingState [731] . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.2. Page 147 - (2023-06) Use case E07 - Scenario description step order incorrect [704] . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.3. Page 148 - (2023-06) Use case E07: Wrong triggerReason shown in sequence diagram fig. 56 [687] . . . . . . . . . . . . . . 23
2.6.4. Page 150 - (2023-06) Use case E07: Clarify 'normal' and 'correct' for stoppedReason [693] . . . . . . . . . . . . . . . . . . . . . . 24
2.6.5. Page 168 - (2024-04) - E15.FR.04 SessionStopReq ends authorization [757]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7. Use Case F Remote Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.1. Page 180 - (2023-06) Requirement F03.FR.03 contains wrong precondition [700] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.2. Page 187 - (2023-06) Requirement F06.FR.12 is too strict [707] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.3. Page 187 - (2024-02) Improved precondition of F06.FR.06/07 [719]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8. Use Case G Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8.1. Page 192 - (2023-06) G01.FR.08 contradicts H01.FR.24 [692] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8.2. Page 196 - (2024-02) G03.FR.03/04 improved [750] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.9. Use Case H Reservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.9.1. Page 205 - (2023-06) Missing option to send NotifyEvent instead of StatusNotification [699] . . . . . . . . . . . . . . . . . . . . 28
2.9.2. Page 209 - (2023-06) Remark about authorization in use case H03 [711] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9.3. Page 210 - (2023-06) Requirement H03.FR.08 is not clear about groupIdToken lookup [684]. . . . . . . . . . . . . . . . . . . . . 30
2.9.4. Page 210 - (2023-12) Transaction can start even when connector is Reserved [735] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.10. Use Case J Meter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.10.1. Page 224 - (2024-04) 2.2. Clock-Aligned Meter Values: additional note [746] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.10.2. Page 225 - (2024-04) New section: 2.5 Configuration Examples [746] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.10.3. Page 227 - (2024-04) J01.FR.14 Improved requirements for clock-aligned values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.10.4. Page 228 - (2023-06) Requirement J01.FR.14 is unclear that meter values for all EVSEs must be sent [674] . . . . . . 32
 2.10.5. Page 230 - (2023-06) Requirement J02.FR.10 refers to all TransactionEventRequest messages, but should be
specific to only eventType = Updated [705] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.10.6. Page 230 - (2024-04) J02.FR.11 Improved requirements for sampled values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.10.7. Page 231 - (2023-06) J01 misses requirement that meter value must be for current transaction [673]. . . . . . . . . . . . 34
2.11. Use Case K Smart Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.11.1. Page 238 - (2023-06) Text in section 3.3 does not match ChargingProfileKindEnumType description [708] . . . . . . . 34
2.11.2. Page 245 - (2024-04) - K01.FR.29 also accepts NotImplemented [755] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.11.3. Page 274 - (2024-02) Transactions for ISO15118 do not support TxStartPoints EnergyTransfer/DataSigned [763] . 35
2.11.4. Page 276 - (2023-12) Requirement K15.FR.15 has wrong precondition [716] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.12. Use Case L FirmwareManagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.12.1. Page 287 - (2023-06) Improved title of figure 119 [695] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.12.2. Page 288 - (2024-02) L01 InstallScheduled when waiting for transaction [729] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.12.3. Page 292 - (2024-02) L02 InstallScheduled when waiting for transaction [729] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.12.4. Page 288/292 - (2024-02) Add support for A/B firmware updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.12.5. Page 289 - (2024-02) Allow DownloadFailed/InstallationFailed when AcceptedCanceled [733] . . . . . . . . . . . . . . . . . . 39
2.13. Use Case M ISO 15118 CertificateManagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.13.1. Page 310 - (2023-06) M04.FR.07 has an incorrect requirement definition [703] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.14. Use Case N Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.14.1. Page 317 - (2023-06) N01.FR.10 not clear when to report UploadFailure [696] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.14.2. Page 331 - (2023-06) Requirement N09.FR.04 has been rephrased [688] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.15. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.15.1. Page 353 - (2023-06) Clarification for use of certificate and iso15118CertificateHashData in AuthorizeRequest
[675] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
AuthorizeRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.15.2. Page 381 - (2023-06) Updated description for idToken in TransactionEventRequest [709] . . . . . . . . . . . . . . . . . . . . . . 41
2.16. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.16.1. Page 386 - (2023-06) issuerKeyHash in CertificateHashDataType must be type identifierString [691] . . . . . . . . . . . . 41
2.16.2. Page 387 - (2024-02) 2.10 Description of chargingSchedule [743] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.16.3. Page 392 - (2024-02) EventDataType minor update of field trigger [740] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.16.4. Page 396 - (2023-06) NetworkConnectionProfileType [683]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.16.5. Page 396 - (2023-12) NetworkConnectionProfileType [713]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.16.6. Page 404 - (2024-02) VariableCharacteristicsType.valuesList [725] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.17. Enumerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.17.1. Page 416 - (2024-02) Description for FirmwareStatusEnumType InstallRebooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.17.2. Page 419 - (2023-06) Description for idTokenEnumType MacAddress [664]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.17.3. Page 427 - (2024-02) 3.68 RecurrencyKindEnumType [749]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.18. Referenced Components and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.18.1. Page 436 - (2023-12) Incorrectly referencing unit = "seconds" instead of "s" [726] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.18.2. Page 436 - (2023-06) Websocket-related variables in Part 4 [690] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.18.3. Page 444 - (2023-06) SecurityCtrlr.BasicAuthPassword and Identity should have dataType=string . . . . . . . . . . . . . . 45
2.18.4. Page 447 - (2024-02) 2.3.8 DisableRemoteAuthorization [751] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.18.5. Page 452 - (2023-06) Incomplete description TxStopPoint Authorized and PowerPathClosed [704] . . . . . . . . . . . . . . 47
2.18.6. Page 454 - (2024-04) SampledDataTxEndedMeasurands/Interval: updated description[746]. . . . . . . . . . . . . . . . . . . . 47
2.18.7. Page 454 - (2024-04) AlignedDataMeasurands/Interval: updated description [746] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.18.8. AlignedDataMeasurands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.18.9. Page 469 - (2024-02) ProtocolSupportedByEV is read-only [734] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.19. Appendix 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.19.1. Page 2 - (2023-06) InvalidFirmwareSignature/SigningCertificate are critical security events [682] . . . . . . . . . . . . . . . 50
2.20. Appendix 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.20.1. Page 9 - (2023-06) OCPPCommCtrlr.ActiveNetworkProfile must be of type integer [697] . . . . . . . . . . . . . . . . . . . . . . . 50
2.20.2. Page 10 - (2023-06) SecurityCtrlr.BasicAuthPassword and Identity should have dataType=string [698] . . . . . . . . . . . 50
2.21. Appendix 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.21.1. Page 36 - (2023-12) ReasonCodes MissingDeviceModelInfo and InvalidMessageSequence exceed 20 chars [720] . 50
3. Part 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4. Part 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1. Page 8 - (2023-12) - section 3.1.2. No OCPP version in endpoint URL [732]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2. Page 10 - (2023-12) - Section 4.1.4. The message ID must be unique [702] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3. Page 10 - (2024-02) 4.1.4 The message ID [738] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5. Part 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
 5.1. Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.1. Page 7 - (2024-02) - Optional feature list for charging station - C-43 - incorrect variable reference at description . . . . 55
5.1.2. Page 7 - (2024-04) - Optional feature list for charging station - C-43 - description extended . . . . . . . . . . . . . . . . . . . . . . 55
5.2. List of test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.1. Page 11 - (2023-12) - TC_B_08_CS should not be tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.2. Page 13 - (2023-12) - TC_B_50_CS - Testcase not only applicable for AdditionalRootCertificateCheck = true . . . . . . . 55
5.2.3. Page 13-23 - (2023-12) - A number of test cases cannot be run for a Charging Station that only supports
NoAuthorization as a local authorization option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.4. Page 19 - (2023-12) - TC_E_20_CS Improved condition / remark and aligned the conditions at feature no. . . . . . . . . . 58
5.2.5. Page 20 - (2023-12) - TC_E_54_CS Improved condition / remark and aligned the conditions at feature no. . . . . . . . . . 59
5.2.6. Page 21 - (2023-12) - TC_E_39_CS - Testcase not only applicable for TxStopPoint Authorized . . . . . . . . . . . . . . . . . . . 60
5.2.7. Page 22 - (2024-02) - TC_E_31_CS - Changed mandatory testcase to conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.8. Page 24 - (2023-12) - TC_F_04_CS should only be applicable when TxStartPoint Authorized or
ParkingBayOccupancy are supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.9. Page 24 - (2024-02) - TC_F_04_CS - condition needs to be kept inline with TC_E_05_CS . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.10. Page 28 - (2024-04) - TC_L_14_CS and TC_L_15_CS - name changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.11. Page 29 - (2024-02) - TC_M_23_CS - testcase is mandatory for Advanced Security, not for Core. . . . . . . . . . . . . . . . . 63
5.2.12. Page 32 - (2024-04) - Added testcase list for the other certification profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6. Part 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1. Test Cases Charging Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.1. Page 3 - (2023-12) - General tool rules/validations - Added information for idToken type NoAuthorization. . . . . . . . . . 65
6.1.2. Page 24 - (2024-04) - TC_A_22_CS - Fixed wrong description of test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.3. Page 30 - (2023-12) - TC_B_30_CS - Removed prerequisite and added note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.4. Page 36 - (2023-12) - TC_B_08_CS - Removed testcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.5. Page 42 - (2023-12) - TC_B_11_CS - Changed hardcoded values for integer and decimal to configurable values . . . . 66
6.1.6. Page 50 - (2023-12) - TC_B_21_CS - Removed requirement reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.7. Page 56 - (2023-12) - TC_B_41_CS - Typo step reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.8. Page 59 - (2023-12) - TC_B_26_CS - Removed rebooting step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.9. Page 64/66 - (2023-12) - TC_B_45_CS & TC_B_46_CS - Testcase has been made more robust for Charging
Stations that do not automatically reboot.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1.10. Page 68-72 - (2023-12) - TC_B_45_CS-TC_B_50_CS - Resolved testcase inconsistency regarding used
configuration slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1.11. Page 72 - (2023-12) - TC_B_50_CS - Testcase not only applicable for AdditionalRootCertificateCheck = true . . . . . . 68
6.1.12. Page 72 - (2024-02) - TC_B_50_CS - This testcase requires that the Charging Station is connected with security
profile 2 or 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.1.13. Page 77 - (2023-12) - TC_B_53_CS - Removed Component / variable list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.1.14. Page 84 - (2024-04) - Local Stop Transaction - Different idToken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.1.15. Page 82-99 - (2023-12) - TC_C_02_CS-TC_C_57_CS - A number of test cases cannot be run for a Charging Station
that only supports NoAuthorization as a local authorization option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.1.16. Page 93 - (2023-12) - TC_C_15_CS - Improvements based on experience from additional testing . . . . . . . . . . . . . . . . 70
6.1.17. Page 101 - (2023-12) - TC_C_33_CS - Fixed broken table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1.18. Page 104 - (2023-12) - TC_C_37_CS - Editorial issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1.19. Page 87-97 and 168/169/170 - TC_E_43_CS/TC_E_44_CS/TC_E_45_CS and Caching test cases - When a
Charging Station supports ISO 15118 these test cases need to be executed using EIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1.20. Page 129 - (2024-02) - TC_E_17_CS - Improved note regarding execution of manual action present idToken . . . . . . 72
6.1.21. Page 131 - (2023-12) - TC_E_39_CS - Removed (local) indication on Authorized reusable state. . . . . . . . . . . . . . . . . . 72
6.1.22. Page 131 - (2023-12) - TC_E_39_CS - Made testcase more flexible to handle all TxStart/StopPoint combinations . . 72
6.1.23. Page 140 - (2024-04) - TC_E_37_CS - EVDisconnected and StoppedByEV both allowed . . . . . . . . . . . . . . . . . . . . . . . . 73
6.1.24. Page 143 - (2023-12) - TC_E_14_CS - Explicitly describe it is allowed to omit the stoppedReason in case of Local. . 74
6.1.25. Page 153 - (2024-04) - TC_E_27_CS Update of prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.1.26. Page 158 - (2023-12) - TC_E_31_CS - Made testcase more robust and flexible regarding local / remote start/stop . 75
6.1.27. Page 158 - (2024-02) - TC_E_31_CS - Updated prerequisite description is confusing. . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.1.28. Page 166/167 - (2023-12) - TC_E_42_CS & TC_E_51_CS - Refined the tool validation of the testcase . . . . . . . . . . . . . 76
6.1.29. Page 174 - (2023-12) - TC_F_04_CS - Missing prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1.30. Page 207 - (2023-12) - TC_G_13_CS - Charging Station does not have to report the status of the connector . . . . . . . 76
6.1.31. Page 217/219/223 - (2023-12) - TC_J_01_CS & TC_J_02_CS & TC_J_06_CS - It is currently not possible to send a
NotifyEventRequest instead of a MeterValuesRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.1.32. Page 226 - (2024-04) - Context Transaction.Begin used once evseId is known. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.1.33. Page 232-265 - (2023-12) - TC_L_XX_CS - Update testcase structure L group testcases. . . . . . . . . . . . . . . . . . . . . . . . 79
 6.1.34. Page 241 - (2023-12) - TC_L_05_CS - Added main step and tool validation for SecurityEventNotification
InvalidFirmwareSigningCertificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.1.35. Page 245 - (2024-02) - TC_L_08_CS - Resolved issues after L test cases rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.1.36. Page 259 - (2024-04) - TC_L_14_CS - Updated to support A/B firmware updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.1.37. Page 262 - (2024-04) - TC_L_15_CS - Updated to support A/B firmware updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.1.38. Page 268 - (2024-04) - TC_M_01_CS - Incorrect note about AdditionalRootCertificateCheck and new CSMSRoot
needs to be installed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.1.39. Page 268-281 - (2023-12) - TC_M_XX_CS - Testcases only applicable when security profile 2 or 3 is supported. . . 141
6.1.40. Page 269/276 - (2023-12) - TC_M_02_CS & TC_M_13_CS & TC_M_17_CS & TC_M_18_CS - Only applicable when
signed firmware update is supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.1.41. Page 279 - (2024-04) - TC_M_19_CS - Removing MORootCertifiate in preparation phase when needed . . . . . . . . . . 142
6.1.42. Page 282 - (2023-12) - TC_M_23_CS - Testcase only applicable when security profile 3 is supported. . . . . . . . . . . . 142
6.1.43. Page 284 - (2023-12) - TC_N_26_CS - Require a minimal size for the configured retry interval, based on the
upload speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.1.44. Page 293 - (2023-12) - TC_N_36_CS - Missing prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.1.45. Page 292/293 - (2023-12) - TC_N_35_CS & TC_N_36_CS - Invalid prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.1.46. Page 308 - (2023-12) - Reusable State: EnergyTransferSuspended - Increased flexibility to support Charging
Stations with high level communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.2. Test Cases Charging Station Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.2.1. Page 380 - (2023-12) - TC_E_39_CSMS - Missing requirement reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.2.2. Page 384 - (2023-12) - TC_E_21_CSMS - Missing requirement reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.2.3. Page 400 - (2023-12) - TC_E_31_CSMS - Added missing StatusNotification steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.2.4. Page 407 - (2023-12) - TC_F_04_CSMS - Missing requirement reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.2.5. Page 447 - (2023-12) - TC_L_05_CSMS - Added missing SecurityEventNotification steps. . . . . . . . . . . . . . . . . . . . . . . 144
6.2.6. Page 448 - (2023-12) - TC_L_06_CSMS - Added missing SecurityEventNotification steps. . . . . . . . . . . . . . . . . . . . . . . 144
6.2.7. Page 473 - (2023-12) - TC_E_32_CSMS - Added missing NotifyCustomerInformation steps. . . . . . . . . . . . . . . . . . . . . 145
6.2.8. Page General - (2024-04) - Added testcase list for the other certification profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Disclaimer
Copyright © 2010 – 2024 Open Charge Alliance. All rights reserved.

This document is made available under the *Creative Commons Attribution-NoDerivatives 4.0 International Public License*
(https://creativecommons.org/licenses/by-nd/4.0/legalcode).

Version History

Version Date Description

2024-04 2024-04-30 Includes new errata for Part 2, Part 5 and Part 6 of OCPP 2.0.1 Edition
2.

2024-02 2024-02-28 Includes new errata for Part 2, Part 4, Part 5 and Part 6 of OCPP 2.0.1.

2023-12 2023-12-18 Includes new errata for Part 1, Part 2, Part 4, Part 5 and Part 6 of
OCPP 2.0.1

1.0 → 2023-06 2023-06-30 Release of Edition 2 Errata v1.0

(v1) changes are now marked as (2023-06)

OCPP 2.0.1 - © Open Charge Alliance 2024 1/145 Edition 2 - Errata 2024-04
Scope
This document contains errata on the OCPP 2.0.1 documentation. These errata have to be read as an addition to the release of
OCPP 2.0.1 Edition 2.

The errata do not affect any schemas of OCPP messages. Certain errata do contain changes to requirements or even new
requirements, but only in cases where a requirement contains an obvious error and would not or could not be implemented literally.
New requirements are only added when they were already implicitly there. These changes have been discussed in or were proposed
by the Technology Working Group of the Open Charge Alliance.

The appendices of the OCPP specification can be updated without requiring a new OCPP release. This mainly concerns the
components and variables of the OCPP device model, which can be extended with new components or variables, as long as they
are optional.

Terminology and Conventions

Bold: when needed to clarify differences, bold text might be used.

The errata entries are sorted by page number of the affected section of the specification document. When an errata entry affects
multiple parts of the specification, then the various changes are grouped together with subsections referring to the pages affected
by those changes.

This is version 2024-04 of the errata. The errata of this version are marked with "(2024-04)" in the section title.

Where possible the issue number by which it was reported, is added in square brackets at the end of the section title, e.g. "[349]".
For retrieval of the issue in the issue tracking system prefix the number with "OCPP20M", like "[OCPP20M-349]".

OCPP 2.0.1 - © Open Charge Alliance 2024 2/145 Edition 2 - Errata 2024-04
0. Part 0
Generic
Part 0 was still referring to "OCPP 2.0". This has been updated to refer to "OCPP 2.0.1" throughout the document.

OCPP 2.0.1 - © Open Charge Alliance 2024 3/145 Edition 2 - Errata 2024-04
1. Part 1
1.1. Device Model: Addressing Components and Variables

1.1.1. Page 6 - (2023-12) - section 4.1 Components: Clarification about tiers for
EVSE/Connector components
It was not made explicit in the text, that the EVSE component must be addressed as being part of the EVSE tier. Similarly, a
Connector component must be at the connector tier. This is shown correctly in the tables for "Basic home charging example
configuration" and "Public home charger example configuration", but was not mentioned explicitly.

Therefore, this sentence is extended, as follows:

After this text ChargingStation (TopLevel), EVSE, and Connector represent the three major "tiers" of a Charging Station, and
constitute an implicit "location-based" addressing scheme that is widely used in many OCPP data structures.
Add new text Each "tier" has a component of the same name, which represents the tier. For example, EVSE 1 on a Charging
Station is represented by the component named "EVSE" (no instance name) with "evseId = 1". In the same
manner, Connector 1 on EVSE 1 is represented by the component named "Connector" (no instance name)
with "evseId = 1, connectorId = 1".

1.1.2. Page 10 - (2023-12) - GetBaseReport supported 'ReportBases' [350]

The table with use cases that are part of a Minimum Device Model implementation has an error for "B07 Get Base Report". Replace
the text as follows:

Old text GetBaseReport message MUST be implemented and MUST support all 3 ‘ReportBases’.
New text GetBaseReport message MUST be implemented and MUST support ConfigurationInventory and
FullInventory.

OCPP 2.0.1 - © Open Charge Alliance 2024 4/145 Edition 2 - Errata 2024-04
2. Part 2
2.1. General

2.1.1. Page 4 - (2024-02) 2.1.4. Definition of data type AnyType [747]

AnyType can hold any data, not just text. The description mentions text and data, which may be confusing. "Text" has been
removed.

Primitive Datatypes
The specification mentions the following primitive datatypes:

Primitive Datatypes

Datatype Description
Old AnyType Text, data without specified length or format.
New AnyType Text, Data without specified length or format.

2.1.2. Page 15 - (2024-04) 3. Generic requirements [759]

Requirement FR.05 intends to explain that a response for the request must be sent before the follow-up message. What exactly is a
"follow-up" message is not properly defined. The requirement should have mentioned that this is for the same requestId.

Updated requirement

Table 1. Generic requirements

ID Precondition Requirement definition Note
Old FR.05 There are a few messages that do The Charging Station SHALL acknowledge the The CSMS needs to
not provide their result in the requests in the list below with a response know that a request
response message, but send one message first, before sending the follow-up was accepted, so that
or more messages that contain the message shown after the arrow (→): it can expect result
result. When one of the following messages.
GetReport → NotifyReport
messages is received; GetReport,
GetBaseReport, GetBaseReport → NotifyReport
GetMonitoringReport, GetMonitoringReport →
GetDisplayMessages, NotifyMonitoringReport
CustomerInformation,
GetDisplayMessages → NotifyDisplayMessage
GetChargingProfiles, GetLog,
UpdateFirmware, PublishFirmware, CustomerInformation →
TriggerMessage(<message>) NotifyCustomerInformation
GetChargingProfiles → ReportChargingProfiles
GetLog → LogStatusNotification
UpdateFirmware →
FirmwareStatusNotification
PublishFirmware →
PublishFirmwareStatusNotification
TriggerMessage(<message>) → <requested
message>

OCPP 2.0.1 - © Open Charge Alliance 2024 5/145 Edition 2 - Errata 2024-04
New FR.05 There are a few messages that do The Charging Station SHALL acknowledge the The CSMS needs to
not provide their result in the requests in the list below with a response know that a request
response message, but send one message first, before sending the follow-up for requestId = X was
or more messages that contain themessage (shown after the arrow "→") with the accepted, so that it
result. When one of the following can expect result
same requestId as the request:
messages is received: messages for this
GetReport → NotifyReport,
GetReport, GetBaseReport, requestId .
GetMonitoringReport, GetBaseReport → NotifyReport, TriggerMessage does
GetDisplayMessages, GetMonitoringReport → not have a requestId ,
CustomerInformation, NotifyMonitoringReport, but the requirement
GetChargingProfiles, GetLog, still applies in the
GetDisplayMessages →
UpdateFirmware, PublishFirmware, sense that a
TriggerMessage(<message>) NotifyDisplayMessage, TriggerMessageRespo
CustomerInformation → nse must be sent
NotifyCustomerInformation, before the sending the
requested message.
GetChargingProfiles →
ReportChargingProfiles,
GetLog → LogStatusNotification,
UpdateFirmware →
FirmwareStatusNotification,
PublishFirmware →
PublishFirmwareStatusNotification,
TriggerMessage(<message>) → <requested
message>.

2.2. Use case A Security

2.2.1. Page 23 - (2023-06) Requirement A00.FR.316: Make clear that

InvalidTLSVersion must be queued [689]
Requirement A00.FR.316 states that a security event InvalidTLSVersion is triggered and connection must be closed. It is not clear
from this requirement that this must also be sent as a security event notification when a connection to CSMS is made. This is
stated in use case A04. Obviously, once CSMS accepts the connection, the InvalidTLSVersion condition no longer applies at this
time, but the event must still be reported.

Changed requirement

ID Precondition Requirement definition

Old text A00.FR.316 A00.FR.314 The Charging Station SHALL trigger an InvalidTLSVersion
security event AND terminate the connection (See part 2
AND
appendices for the full list of security events).
The Charging Station detects
that the CSMS only allows
connections using an older
version of TLS, or only allows
SSL
New text A00.FR.316 A00.FR.314 The Charging Station SHALL trigger an InvalidTLSVersion
security event AND terminate the connection (See part 2
AND
The Charging Station detects appendices for the full list of security events).
that the CSMS only allows
connections using an older NOTE: This is a critical security event that will need to be
version of TLS, or only allows queued and sent to CSMS once a successful connection has
SSL been made, as described in use case A04.
A security event only needs to be sent once for repeated failed
connection attempts, in order to avoid overflow to the offline
queue.

Page 25 - Requirement A00.FR.419

Changed requirement

OCPP 2.0.1 - © Open Charge Alliance 2024 6/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition
Old text A00.FR.419 A00.FR.417 The Charging Station SHALL trigger an InvalidTLSVersion
security event AND terminate the connection (See part 2
AND
appendices for the full list of security events).
The Charging Station detects
that the CSMS only allows
connections using an older
version of TLS, or only allows
SSL
New text A00.FR.419 A00.FR.417 The Charging Station SHALL trigger an InvalidTLSVersion
security event AND terminate the connection (See part 2
AND
The Charging Station detects appendices for the full list of security events).
that the CSMS only allows
connections using an older NOTE: This is a critical security event that will need to be
version of TLS, or only allows queued and sent to CSMS once a connection has been made, as
SSL described in use case A04.
A security event only needs to be sent once for repeated failed
connection attempts, in order to avoid overflow to the offline
queue.

2.2.2. Page 31 - (2024-02) A02 - Update Charging Station Certificate by request of

CSMS [744]
The use case A02 has been extended with an alternative scenario that describes how to request a SignV2GCertificate if the
Charging Station has multiple SECC’s (e.g. one for each EVSE).

A02 - Update Charging Station Certificate by request of CSMS

No. Type Description

1 Name Update Charging Station Certificate by request of CSMS
2 ID A02
Functional block A. Security
3 Objective(s) To facilitate the management of the Charging Station client side certificate, a certificate update
procedure is provided.
4 Description The CSMS requests the Charging Station to update its key using TriggerMessageRequest with the
requestedMessage field set to SignChargingStationCertificate (or SignV2GCertificate for separate
15118 certificate).

If the Charging Station has a separate ISO15118Ctrlr (SECC in ISO 15118) for each EVSE, then
CSMS will have to send a request for each of them. The device model the Charging Station will tell
if ISO15118Ctrlr is located at toplevel or EVSE-level.
If the Charging Station has multiple SECCs that each control multiple EVSEs, then these are
represented in device model by an ISO15118Ctrlr for each EVSE. The EVSEs that are controlled by
the same SECC report an ISO15118Ctrlr with the same "SeccId".
Actors Charging Station, CSMS, Certificate Authority Server

OCPP 2.0.1 - © Open Charge Alliance 2024 7/145 Edition 2 - Errata 2024-04
 No. Type Description
Scenario description SignChargingStationCertificate

1. The CSMS requests the Charging Station to update its certificate using the
TriggerMessageRequest with the requestedMessage field set to SignChargingStationCertificate
(or SignV2GCertificate for separate 15118 certificate).
2. The Charging Station responds with TriggerMessageResponse
3. The Charging Station generates a new public / private key pair.
4. The Charging Station sends a SignCertificateRequest to the CSMS containing the
certificateType = ChargingStationCertificate .
5. The CSMS responds with SignCertificateResponse, with status Accepted.
6. The CSMS forwards the CSR to the Certificate Authority Server.
7. Certificate Authority Server signs the certificate.
8. The Certificate Authority Server returns the Signed Certificate to the CSMS.
9. The CSMS sends CertificateSignedRequest to the Charging Station.
10. The Charging Station verifies the Signed Certificate.
11. The Charging Station responds with CertificateSignedResponse to the CSMS with the status
Accepted or Rejected.
Alternative scenario SignV2GCertificate

1. CSMS requests information about component ISO15118Ctrlr by sending a GetReportRequest

for componentVariable.component = "ISO15118Ctrlr" and componentVariable.variable = "SeccId".
2. For each unique SeccId that is returned:

2.1. The CSMS requests the Charging Station to update its certificate using the
TriggerMessageRequest with the requestedMessage field set to SignV2GCertificate for a 15118
certificate, and evse set to the EVSE of the ISO15118Ctrlr. (If ISO15118Ctrlr only exists as one
component at toplevel, then evse can be omitted.)
2.2. The Charging Station responds with TriggerMessageResponse
2.3. The Charging Station generates a new public / private key pair.
2.4. The Charging Station sends a SignCertificateRequest to the CSMS containing the
certificateType = V2GCertificate and a csr in which the CommonName (CN) is set to the value
of SeccId.
2.5. CSMS responds with SignCertificateResponse, with status Accepted.
2.6. The CSMS forwards the CSR to the Certificate Authority Server.
2.7. Certificate Authority Server signs the certificate.
2.8. The Certificate Authority Server returns the Signed Certificate to the CSMS.
2.9. The CSMS sends CertificateSignedRequest to the Charging Station.
2.10. The Charging Station verifies the Signed Certificate.
2.11. The Charging Station responds with CertificateSignedResponse to the CSMS with the status
Accepted or Rejected.
5 Prerequisite(s) The standard configuration variable "OrganizationName" MUST be set. For SignV2GCertificate the
variable ISO15118Ctrlr.SeccId must be set.
6 Postcondition(s) Successful postcondition:
New Client Side certificate installed in the Charging Station.
Failure postcondition:
New Client Side certificate is rejected and discarded.

2.3. Use case B Provisioning

2.3.1. Page 51 - (2023-12) Requirement B03.FR.08 incorrect, and B03.FR.03

rephrased [712]
Requirement B03.FR.08 suggests that CSMS can send a TriggerMessage(BootNotification) after it has rejected the Charging
Station. This is not possible.

OCPP 2.0.1 - © Open Charge Alliance 2024 8/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition
Old B03.FR.03 While in the status Rejected. The CSMS SHALL NOT initiate any messages.
New B03.FR.03 When the CSMS has Rejected the The CSMS SHALL NOT initiate any messages.
BootNotificationRequest from the
Charging Station.
Old B03.FR.08 B03.FR.03 Charging Station SHALL respond with RPC Framework:
CALLERROR: SecurityError.
AND
CSMS sends a message that is not a
TriggerMessageRequest(requestedMessa
ge = BootNotification)
New B03.FR.08 B03.FR.03 Charging Station SHALL respond with RPC Framework:
CALLERROR: SecurityError.
AND
CSMS sends a message that is not a
response to a BootNotificationRequest
from Charging Station

2.3.2. Page 51 - (2023-12) Typo in B03.FR.06 [736]

ID Precondition Requirement definition
Old B03.FR.06 If the interval in the The Charging Station SHALL send a
BootNotificationResponse is greater than BootNotificationRequest after the set interval has past.
0, and the status is other than Accepted
New B03.FR.06 If the interval in the The Charging Station SHALL send a
BootNotificationResponse is greater than BootNotificationRequest after the set interval has
0, and the status is other than Accepted passed .

2.3.3. Page 61 - (2023-06) Requirement B08.FR.19 and N02.FR.15 are ambiguous

w.r.t. evse and instance wildcards [676]
Requirement B08.FR.19 tries to catch multiple situations in one requirement, but as a result it is no longer unambiguous. The
requirement has therefore been split into multiple requirements, but with the same intention as B08.FR.19.

Delete requirement

ID Precondition Requirement definition

B08.FR.19 When Charging Station receives a The Charging Station SHALL report for every instance and/or
GetReportRequest with componentVariable EVSE of the component in componentVariable.
elements in which component.instance and/or
component.evse are missing

The following new requirements replace B08.FR.19:

New requirements

ID Precondition Requirement definition

B08.FR.22 B08.FR.11 AND The Charging Station SHALL report the component(s) with this
When Charging Station receives a component.name, component.instance and component.evse.id
GetReportRequest with a component in a for every component.evse.connector, whilst taking into account
componentVariable element that has a B08.FR.24.
component.evse.id, but
component.evse.connector is missing
B08.FR.23 B08.FR.11 AND The Charging Station SHALL report the component(s) with this
When Charging Station receives a component.name, component.instance for every component.evse
GetReportRequest with a component in a field (including top level component without component.evse),
componentVariable element that has no whilst taking into account B08.FR.24.
component.evse.id

OCPP 2.0.1 - © Open Charge Alliance 2024 9/145 Edition 2 - Errata 2024-04
ID Precondition Requirement definition
B08.FR.24 B08.FR.11 AND The Charging Station SHALL report the component(s) with this
When Charging Station receives a component.name for every component.instance field, whilst
GetReportRequest with a component in a taking into account B08.FR.22, B08.FR.23.
componentVariable element that has a value for
component.instance
B08.FR.25 B08.FR.11 AND The Charging Station SHALL report the component(s) with this
When Charging Station receives a component.name for every component.instance field or the
GetReportRequest with a component in a component(s) without component.instance field, whichever is
componentVariable element that has no the case, whilst taking into account B08.FR.22, B08.FR.23.
component.instance field

Page 319 - N02.FR.15

Exactly the same applies, mutatis mutandis, for requirement N02.FR.15.

Delete requirement

ID Precondition Requirement definition

N02.FR.15 When Charging Station receives a The Charging Station SHALL report for every instance and/or
GetMonitoringReportRequest EVSE of the component in componentVariable.
with_componentVariable_ elements in which
component.instance and/or component.evse are
missing

New requirements

ID Precondition Requirement definition

N02.FR.18 N02.FR.11 AND The Charging Station SHALL report the component(s) with this
When Charging Station receives a component.name, component.instance and component.evse.id
GetMonitoringReportRequest with a component for every component.evse.connector, whilst taking into account
in a componentVariable element that has a N02.FR.20.
component.evse.id, but
component.evse.connector is missing
N02.FR.19 N02.FR.11 AND The Charging Station SHALL report the component(s) with this
When Charging Station receives a component.name, component.instance for every component.evse
GetMonitoringReportRequest with a component field (including top level component without component.evse),
in a componentVariable element that has no whilst taking into account N02.FR.20.
component.evse.id
N02.FR.20 N02.FR.11 AND The Charging Station SHALL report the component(s) with this
When Charging Station receives a component.name for every component.instance field, whilst
GetMonitoringReportRequest with a component taking into account N02.FR.18, N02.FR.19.
in a componentVariable element that has a value
for component.instance
N02.FR.21 N02.FR.11 AND The Charging Station SHALL report the component(s) with this
When Charging Station receives a component.name for every component.instance field or the
GetMonitoringReportRequest with a component component(s) without component.instance field, whichever is
in a componentVariable element that has no the case, whilst taking into account N02.FR.18, N02.FR.19.
component.instance field

2.3.4. Page 62 - (2023-06) Use case B09/B10: Extended scenario description [683]
Use case B09 describes the setting of a NetworkConnectionProfile and use case B10 describes how to use
NetworkConnectionProfiles to migrate a Charging Station to a new CSMS. The relationship with the variable
OCPPCommCtrlr.NetworkConfigurationPriority was not made explicit. The use case descriptions have been updated for that.

Use case B09

The text marked in bold has been added to the scenario description.

OCPP 2.0.1 - © Open Charge Alliance 2024 10/145 Edition 2 - Errata 2024-04
No. Type Description
1 Name Setting a new NetworkConnectionProfile.
2 ID B09
Functional block B. Provisioning
3 Objectives To enable the CSMS to update the connection details on the Charging Station.
4 Description The CSMS updates the connection details on the Charging Station. For instance in preparation of
a migration to a new CSMS. After completion of this use case, the Charging Station to CSMS
connection data has been updated.
Actors Charging Station, CSMS
Scenario description A Charging Station supports at least two network configuration slots, that are identified by a
number. The available slot numbers are reported by the Charging Station in the valuesList of
variable NetworkConfigurationPriority.
For example: valuesList = "0,1,2" in the base report tells CSMS that three configuration slots,
numbered 0, 1 and 2, are available (but not necessarily set).
The configuration slot number that is used for the active connection is reported by variable
OCPPCommCtrlr.ActiveNetworkProfile.

1. The CSMS sends a SetNetworkProfileRequest PDU containing an updated connection profile

and a configurationSlot out of the valuesList of NetworkConfigurationPriority.
2. The Charging Station receives the PDU, validates the content and stores the new data
3. The Charging Station responds by sending a SetNetworkProfileResponse PDU, with status
Accepted
5 Prerequisites The data supplied by the CSMS matches the Charging Station’s capabilities
6 Postcondition(s) The Charging Station was able to store the new connection data

Requirement for configuration slots

A Charging Station must support at least two configuration slots for network profiles in order to support a migration. The number of
the configuration slot must match an entry in the valuesList of the NetworkConfigurationPriority.

This was already implicitly required, or else the use case B09 and B10 would not work. It is now made explicit in the following new
requirements.

New requirements

ID Precondition Requirement definition

B09.FR.05 When the value of configurationSlot in The Charging Station SHALL respond by sending a
SetNetworkProfileRequest does not match an SetNetworkProfileResponse message with status Rejected
entry in valuesList of
NetworkConfigurationPriority
B09.FR.06 A Charging Station SHALL support at least two configuration
slots for network connection profiles.

Use case B10

The text marked in bold has been added to the scenario description.

No. Type Description

1 Name Migrate to new CSMS, using a different NetworkConnectionProfile.
2 ID B10
Functional block B. Provisioning
3 Objectives After completion of this use case, the Charging Station connects to a new CSMS.
4 Description This use case describes how a Charging Station can be instructed to connect to a new CSMS, by
changing the order of NetworkConnectionProfiles in NetworkConfigurationPriority.
Actors Charging Station, CSMS 1, CSMS 2

OCPP 2.0.1 - © Open Charge Alliance 2024 11/145 Edition 2 - Errata 2024-04
No. Type Description
Scenario description A Charging Station supports at least two network configuration slots, that are identified by a
number. The available slot numbers are reported by the Charging Station in the valuesList of
variable NetworkConfigurationPriority.
For example: valuesList = "0,1,2" in the base report tells CSMS that three configuration slots,
numbered 0, 1 and 2, are available (but not necessarily set).
The value of NetworkConfigurationPriority reports the order in which network configurations are
tried to make a connection.
For example: value = "1,0" means that Charging Station will first try configuration slot 1 and if
that fails after the number of attempts configured in NetworkProfileConnectionAttempts, it will
try to connect with configuration slot 0.

1. CSMS 1 sets a new value for the NetworkConfigurationPriority configuration variable

via SetVariablesRequest, such that the NetworkConnectionProfile for CSMS 2 becomes first in the
list and the existing connection to CSMS 1 becomes second in the list.
2. The Charging Station responds with a SetVariablesResponse with status Accepted
3. CSMS 1 instructs the Charging Station to perform a Reset OnIdle.
4. The Charging Station reboots and connects via the new primary NetworkConnectionProfile to
CSMS 2.
5 Prerequisites Use case B09 - Setting a new NetworkConnectionProfile was executed successfully prior to this
use case
The data supplied by the CSMS matches the Charging Station’s capabilities
6 Postcondition(s) The Charging Station is connected via a different NetworkConnectionProfile.

2.3.5. Page 65 - (2024-02) Use case B11/12: Reset of EVSE does not cause reboot
of Charging Station [724]
The requirements in B11 and B12 are not clear about the fact that resetting an EVSE does not cause a reboot of the Charging
Station. This is explicitly mentioned in the use case text, but the requirements still use reboot in conjunction with an EVSE.

Page 65 - B11, Figure 20: Reset Without Transaction

The sequence diagram of Figure 20 has been updated to clarify the difference between reset of a Charging Station and EVSE.

OCPP 2.0.1 - © Open Charge Alliance 2024 12/145 Edition 2 - Errata 2024-04
 CSMS Charging Station
CSO

No transaction is active

alt [Reset Charging Station]

reset CS

ResetRequest(OnIdle | Immediate)

ResetResponse(status)

opt [Report all connectors as Unavailable during reset]

loop [for all connectors of all EVSEs]

StatusNotificationRequest(Unavailable, ...)

StatusNotificationResponse()

reboot Charging Station

Continue B01 - Cold Boot Charging Station

[Reset EVSE]
reset EVSE

ResetRequest(OnIdle | Immediate, evseId)

ResetResponse(status)

opt [Report connectors of EVSE as Unavailable during reset]

loop [for all connectors of EVSE]

StatusNotificationRequest(Unavailable, evseId, connectorId)

StatusNotificationResponse()

reset EVSE without reboot

of Charging Station

reset EVSE

opt [Report connectors of EVSE as Available]

loop [for all connectors of EVSE]

StatusNotificationRequest(Unavailable, evseId, connectorId)

StatusNotificationResponse()

Figure 20: Sequence Diagram: Reset Without Transaction

Page 65 - B11 Requirements

Changed requirements

ID Precondition Requirement definition

Old B11.FR.05 If the status of an EVSE was Reserved. After a reboot of the Charging Station or EVSE, the
EVSE(s) SHALL return to the state Reserved.
New B11.FR.05 If the status of an EVSE was Reserved. After a reboot of the Charging Station or resetting of
EVSE, the EVSE(s) SHALL return to the state Reserved.
Old B11.FR.08 B11.FR.01 The Charging Station MAY send a
StatusNotification(Unavailable) for the EVSE and SHALL
AND an evseId parameter is supplied
start a reboot of EVSE that is referred to by evseId
AND parameter.
ResetResponse was Accepted.

OCPP 2.0.1 - © Open Charge Alliance 2024 13/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition
New B11.FR.08 B11.FR.01 The Charging Station MAY send a
StatusNotification(Unavailable) for the EVSE and SHALL
AND an evseId parameter is supplied
start a reset of EVSE that is referred to by evseId
AND parameter.
ResetResponse was Accepted.

Page 68 - B12, Figure 21: Reset With Ongoing Transaction

The sequence diagram of Figure 21 has been updated to clarify the difference between a reset of Charging Station and EVSE. For
clarity it has been split into two diagrams: one for OnIdle and one for Immediate reset.

CSMS Charging Station

CSO

alt [Reset Charging Station]

Transactions active on one or more EVSEs

reset CS

ResetRequest(OnIdle)

ResetResponse(Scheduled)

opt [Avoid starting of new transactions

on free EVSEs]

loop [for all connectors of Available EVSEs]

StatusNotificationRequest(Unavailable,...)

StatusNotificationResponse(...)

Wait for transactions to end,

and optionally set connector(s)
to Unavailable when a transaction ends.

reboot Charging Station

Continue B01 - Cold Boot Charging Station

[Reset EVSE]

Transaction active on EVSE

reset CS

ResetRequest(OnIdle, evseId)

ResetResponse(Scheduled)

Wait for transaction to end,

and optionally set connector(s)
to Unavailable when the transaction ends.

reset EVSE

loop [for all connectors of EVSE]

StatusNotificationRequest(Available, evseId, connectorId)

StatusNotificationResponse()

Figure 21a: Sequence Diagram: Reset OnIdle With Ongoing Transaction

OCPP 2.0.1 - © Open Charge Alliance 2024 14/145 Edition 2 - Errata 2024-04
 CSMS Charging Station
CSO

alt [Reset Charging Station]

Transactions active on one or more EVSEs

reset CS

ResetRequest(Immediate)

ResetResponse(Accepted)

Terminate all transactions,

regardless of TxStopPoint.

loop [for all stopped transactions]

TransactionEventRequest(eventType = Ended, stopReason = ImmediateReset,...)

TransactionEventResponse(...)

reboot Charging Station

Continue B01 - Cold Boot Charging Station

[Reset EVSE]

Transaction active on EVSE

reset CS

ResetRequest(Immediate, evseId)

ResetResponse(Scheduled)

Terminate transaction,
regardless of TxStopPoint.

TransactionEventRequest(eventType = Ended, stopReason = ImmediateReset,...)

TransactionEventResponse(...)
reset EVSE

loop [for all connectors of EVSE]

StatusNotificationRequest(Available, evseId, connectorId)

StatusNotificationResponse()

Figure 21b: Sequence Diagram: Reset Immediate With Ongoing Transaction

Page 68 - B12 Requirements

Changed requirements

ID Precondition Requirement definition

Old B12.FR.05 If an Immediate Reset is received and the The Charging Station SHALL queue the
TransactionEventResponse is not received TransactionEventRequest, reboot and resend the
within timeout. TransactionEventRequest after the reboot.
New B12.FR.05 If an Immediate Reset without evseId is The Charging Station SHALL queue the
received and the TransactionEventRequest, reboot and resend the
TransactionEventResponse is not received TransactionEventRequest after the reboot.
within timeout.
Old B12.FR.06 If the status was set to Inoperative by the After a reboot of the Charging Station or EVSE, the
CSMS. EVSE(s) SHALL return to the state Unavailable as prior to
the reboot.
New B12.FR.06 If the status was set to Inoperative by the After a reboot of the Charging Station or resetting of
CSMS. EVSE, the EVSE(s) SHALL return to the state Unavailable
as prior to the reboot of Charging Station or reset of
EVSE .

OCPP 2.0.1 - © Open Charge Alliance 2024 15/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition
Old B12.FR.07 If an evseId is supplied The transaction on the EVSE SHALL be terminated
normally, before the reboot, as in E06 - Stop Transaction.
AND
If a transaction is in progress on the EVSE
and an OnIdle reset is received.
New B12.FR.07 If an evseId is supplied The transaction on the EVSE SHALL be terminated
normally, before the reset , as in E06 - Stop Transaction.
AND
If a transaction is in progress on the EVSE
and an OnIdle reset is received.
Old B12.FR.08 If an evseId is supplied The Charging Station SHALL attempt to terminate the
transaction in progress on the EVSE and send a
AND
TransactionEventRequest (eventType = Ended) message
If a transaction is in progress on the EVSE
before performing a reboot.
and an Immediate Reset is received.
New B12.FR.08 If an evseId is supplied The Charging Station SHALL attempt to terminate the
transaction in progress on the EVSE and send a
AND
TransactionEventRequest (eventType = Ended) message
If a transaction is in progress on the EVSE
before performing a reset .
and an Immediate Reset is received.

2.4. Use case C Authorization

2.4.1. Page 72 - (2024-04) C 1.4 Local Authorization List [737]

Section C1.3 and the description of IdTokenInfoType state that cacheExpiryDateTime, when present, determines expiration of the
idToken in a cache. Section C1.4 mentions a "corresponding expiration date" for identifiers. The only expiration date on an
IdTokenInfoType is cacheExpiryDateTime.

The text in the second paragraph of C1.4 has been improved to explicitly refer to cacheExpiryDateTime (instead of generic
"expiration date").

Old This list contains the authorization status of all (or a selection of) identifiers and the corresponding expiration date.
These values may be used to provide more fine grained information to users (e.g. by display message) during local
authorization.
New This list contains the authorization status of all (or a selection of) identifiers and the corresponding expiration date
in cacheExpiryDateTime . These values may be used to provide more fine-grained information to users (e.g. by
display message) during local authorization.

2.4.2. Page 90 - (2024-04) C07.FR.05 does not require

iso15118CertificateHashData [761]
The field iso15118CertificateHashData can be omitted if certificate is present. It is not required to use this field to check with OCSP.
CSMS can also calculate hash data from the chain in certificate.

ID Precondition Requirement definition

Old C07.FR.05 C07.FR.02 The CSMS SHALL verify validity of the certificate and
certificate chain via real-time or cached OCSP data using
the hash data provided in iso15118CertificateHashData
field.
New C07.FR.05 C07.FR.02 The CSMS SHALL verify validity of the certificate and
certificate chain via real-time or cached OCSP data. using
the hash data provided in iso15118CertificateHashData
field.

2.4.3. Page 90 - (2023-06) C07 requirements for certificateStatus missing [680]

In case of ISO 15118 Plug&Charge the AuthorizeResponse returns a certificateStatus of type AuthorizeCertificateStatusEnumType.
Requirement C07.FR.04 states that an authorization status must be returned, but the exact values are not defined.

Requirements have been added that describe which values to use for certificateStatus.

OCPP 2.0.1 - © Open Charge Alliance 2024 16/145 Edition 2 - Errata 2024-04
New requirements

ID Precondition Requirement definition Note

C07.FR.13 C07.FR.04 AND CSMS SHALL return an Certificate is valid, but
the certificate chain (provided in certificate or AuthorizationResponse containing a EMAID is not accepted.
certificateStatus =
iso15118CertificateHashData) is valid AND
ContractCancelled and the
authorization status of idToken is one of Blocked,
authorization status in
Expired, Invalid, Unknown
idTokenInfo.status.
C07.FR.14 C07.FR.04 AND CSMS SHALL return an Charging can still not be
the certificate chain (provided in certificate or AuthorizationResponse containing a allowed if
certificateStatus = Accepted and the idTokenInfo.status is
iso15118CertificateHashData) is valid AND
authorization status in other than Accepted
authorization status of idToken is NOT one of
idTokenInfo.status. (e.g. ConcurrentTx or
Blocked, Expired, Invalid, Unknown
NotAtThisLocation).
C07.FR.15 C07.FR.04 AND CSMS SHALL return an If certificate is expired,
the certificate chain (provided in certificate or AuthorizationResponse containing a then status of idToken is
iso15118CertificateHashData) has expired certificateStatus = also reported expired.
CertificateExpired and an
idTokenInfo.status = Expired
C07.FR.16 C07.FR.04 AND CSMS SHALL return an If certificate is revoked,
the certificate chain (provided in certificate or AuthorizationResponse containing a then status of idToken is
iso15118CertificateHashData) has been revoked certificateStatus = reported as invalid.
CertificateRevoked and an
idTokenInfo.status = Invalid
C07.FR.17 C07.FR.04 AND CSMS SHALL return an If certificate is cannot be
the certificate chain (provided in certificate or AuthorizationResponse containing a verified, then status of
iso15118CertificateHashData) cannot be verified or certificateStatus = CertChainError idToken is reported as
is invalid and an idTokenInfo.status = Invalid invalid.

Page 408 - AuthorizeCertificateStatusEnumType

The enumeration AuthorizeCertificateStatusEnumType contains some values that are not used. These enumeration values continue
to exist, so as not to change the JSON schema, but their description is changed to show that these values have no meaning.

Updated text in bold:

AuthorizeCertificateStatusEnumType

Value Description
Accepted Positive response
SignatureError <not used>
CertificateExpired If the contract certificate in the AuthorizeRequest is expired.
CertificateRevoked If the Charging Station or CSMS determine (via a CRL or OCSP response) that the contract certificate in the
AuthorizeRequest is marked as revoked.
NoCertificateAvailab <not used>
le
CertChainError If the contract certificate contained in the AuthorizeRequest message is not valid.
ContractCancelled If the EMAID provided by EVCC is invalid, unknown, expired or blocked.

2.4.4. Page 97 - (2023-06) Requirement C10.FR.06 needs to be removed [685]

Requirement C10.FR.06 is an invalid requirement, because the ReserveNowRequest does not contain IdTokenInfo, so there is no
information to update the Authorization Cache with.

Deleted requirement

OCPP 2.0.1 - © Open Charge Alliance 2024 17/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
C10.FR.06 Upon receipt of ReserveNowRequest. The Charging Station SHALL update the The update is to be done
Authorisation Cache entry. with the IdTokenInfo
value from the request as
described under
Authorization Cache.

Page 96 - Update sequence diagram

As a result of the above, the "for ReserveNowRequest" part has been removed from sequence diagram "Figure 31".

Charging Station CSMS

alt [for AuthorizeResponse]

AuthorizeRequest(...)

AuthorizeResponse(idTokenInfo,...)

Store Authorization Data in

Authorization Cache()

[for TransactionEventResponse]
TransactionEventRequest(...)

TransactionEventResponse(idTokenInfo,...)

Store Authorization Data in

Authorization Cache()

2.4.5. Page 97 - (2024-04) C10 Authorization Cache: cacheExpiryDateTime [737]

Section C1.3 and the description of IdTokenInfoType state that cacheExpiryDateTime, when present, determines expiration of the
idToken in a cache. This has not been made clear in the requirements.

Requirement C10.FR.08 mentions configuration variable AuthCacheLifeTime that limits how long a token may live in the
authorization cache, but cacheExpiryDateTime also determines expiration.

This is now made explicit as a new precondition for C10.FR.08 and a new requirement C10.FR.13.

Changed requirement

ID Precondition Requirement definition Note

Old C10.FR.08 The time a token may live in the cache is This expiry of the
determined by the Configuration Variable cache is not the same
AuthCacheLifeTime. This variable indicates as the expiration date
how long it takes until a token expires in the that is set for the
Authorization Cache since it is last used. IdToken (e.g. RFID
card expiry date).
New C10.FR.08 When IdTokenInfoType does not The time a token is considered to be present in This expiry of the
contain a value for the cache is determined by the Configuration cache is not the same
cacheExpiryDateTime Variable AuthCacheLifeTime. This variable as the expiration date
indicates how long it takes until a token that is set for the
expires in the Authorization Cache since it is IdToken (e.g. RFID
last used. card expiry date).

New requirement

OCPP 2.0.1 - © Open Charge Alliance 2024 18/145 Edition 2 - Errata 2024-04
ID Precondition Requirement definition Note
C10.FR.13 When IdTokenInfoType contains a The time a token is considered to be present in the This expiry of the cache
value for cacheExpiryDateTime cache is determined by cacheExpiryDateTime. This is not the same as the
variable indicates the date and time after which a expiration date that is set
token expires in the Authorization Cache. for the IdToken (e.g. RFID
card expiry date).

2.4.6. Page 102 - (2023-06) Requirement C13.FR.04 enhanced [701]

Requirement C13.FR.04 suggests that any identifier must be accepted, but that was not the intention. In fact, it is in conflict with
use case C15 that describes offline authorization of an unknown identifier. Requirement C15.FR.08 says that any unknown
identifier not in Authorization Cache or Local Authorization List (prerequisite of C15) must be accepted. C13.FR.04 is updated to
reflect this.

Changed requirement

ID Precondition Requirement definition Note

Old text C13.FR.04 If configuration variable Any identifier SHALL be allowed to authorize a
OfflineTxForUnknownIdEnab transaction.
led is true AND
The Charging Station is offline.
New text C13.FR.04 If configuration variable Any identifier that is present in neither the See also C15.FR.08
OfflineTxForUnknownIdEnab Authorization Cache nor the Local
led is true AND Authorization List SHALL be allowed to
The Charging Station is offline. authorize a transaction.

2.4.7. Page 102 - (2024-04) cacheExpiryDateTime requirements [737]

The current OCPP 2.0.1 specification is not clear about whether a Local Authorization List shall respect the cacheExpiryDateTime
field in IdTokenInfo. Explicit requirements for it are missing.

It is convenient for a CSMS to set cacheExpiryDateTime in Local Authorization List to the contract expiration date of the idToken.
This avoids the need for a CSMS to remove an idToken from Local Authorization List at the exact moment that the contract expires.

Page 450 - New configuration variable LocalAuthListSupportsExpiryDateTime

Charging Stations that support cacheExpiryDateTime field in for idTokens in Local Authorization List can now report the device
model variable LocalAuthListCtrlr.SupportsExpiryDateTime as true. When absent the value is regarded to be false.

LocalAuthListSupportsExpiryDateTime

Required no
Component componentName LocalAuthListCtrlr
Variable variableName SupportsExpiryDateTime
variableAttributes mutability ReadOnly
variableCharacteristics dataType boolean
Description When set to true Charging Station will disregard idTokens for authorization as if not present in the Local
Authorization List when current date/time is past the value of cacheExpiryDateTime.
Note, that cacheExpiryDateTime does not affect the behavior of SendLocalListRequest or GetLocalListRequest
messages.

The following new and updated requirements for C13 and C14 only have an effect when configuration
variable LocalAuthListSupportsExpiryDateTime exists and has value true. For an implementation
IMPORTANT
without LocalAuthListSupportsExpiryDateTime that ignores the value of cacheExpiryDateTime in
Local Authorization List there is no functional change to C13 and C14 at all.

Page 102 - C13 Offline Local Authorization List: added cacheExpiryDateTime requirement
Requirement C13.FR.02 has been updated to reflect expiry date in cacheExpiryDateTime.

OCPP 2.0.1 - © Open Charge Alliance 2024 19/145 Edition 2 - Errata 2024-04
Updated requirements

ID Precondition Requirement definition Note

Old C13.FR.02 If configuration variable Only identifiers that are present in a Local
OfflineTxForUnknownIdEnab Authorization List that have a status Accepted
led is false AND SHALL be allowed to authorize a transaction.
The Charging Station is offline.
New C13.FR.02 If configuration variable Only identifiers that are present in a Local This means that
OfflineTxForUnknownIdEnab Authorization List that have a status Accepted Charging Station does
led is false AND SHALL be allowed to authorize a transaction. not check for
The Charging Station is offline cacheExpiryDateTime .
AND
LocalAuthListSupportsExpi
ryDateTime does not exist or is
false
Old C13.FR.04 If configuration variable Any identifier that is present in neither the See also C15.FR.08
OfflineTxForUnknownIdEnab Authorization Cache nor the Local
led is true AND Authorization List SHALL be allowed to
The Charging Station is offline. authorize a transaction.

New C13.FR.04 If configuration variable Any identifier that is present in neither the This means that
OfflineTxForUnknownIdEnab Authorization Cache nor the Local Charging Station does
led is true AND Authorization List SHALL be allowed to not check for
The Charging Station is offline authorize a transaction AND cacheExpiryDateTime .
AND any identifiers that are present in a Local See also C15.FR.08
LocalAuthListSupportsExpi Authorization List that have a status Accepted
ryDateTime does not exist or is SHALL be allowed to authorize a transaction.
false

New requirements

ID Precondition Requirement definition Note

C13.FR.05 If configuration variable Only identifiers that are present in a Local When
OfflineTxForUnknownIdEnabled Authorization List that have a status Accepted and cacheExpiryDateTime is
is false AND for which cacheExpiryDateTime has not passed absent, the idToken will
SHALL be allowed to authorize a transaction. not expire in Local
The Charging Station is offline AND
Authorization List.
LocalAuthListSupportsExpiryD
ateTime = true
C13.FR.06 If configuration variable Any identifier that is present in neither the This means that an
OfflineTxForUnknownIdEnabled Authorization Cache nor the Local Authorization expired token in the
is true AND List SHALL be allowed to authorize a transaction Local Authorization List
AND is not authorized,
The Charging Station is offline AND
because it is not an
LocalAuthListSupportsExpiryD any identifiers that are present in a Local
Authorization List that have a status Accepted and "unknown id".
ateTime = true
for which cacheExpiryDateTime has not passed
SHALL be allowed to authorize a transaction.

Page 103 - C14 Online Local Authorization List: added cacheExpiryDateTime for
Requirement C14.FR.02 has been updated to reflect expiry date in cacheExpireDateTime. Requirement C14.FR.03 has been
simplified by simply referring to "NOT C14.FR.02".

Updated requirement

ID Precondition Requirement definition Note

Old C14.FR.02 Identifiers presented is in the Local The Charging Station SHALL start charging
Authorization List with a status without sending an AuthorizeRequest.
Accepted

OCPP 2.0.1 - © Open Charge Alliance 2024 20/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
New C14.FR.02 Identifier presented is in the Local The Charging Station SHALL start charging This means that
Authorization List with a status without sending an AuthorizeRequest. Charging Station does
Accepted AND not check for
LocalAuthListSupportsExpi cacheExpiryDateTime .
ryDateTime does not exist or is
false

New requirements

ID Precondition Requirement definition Note

C14.FR.04 Identifier presented is in the Local
The Charging Station SHALL start charging without When
Authorization List with a statussending an AuthorizeRequest. cacheExpiryDateTime is
Accepted AND absent, the idToken will
LocalAuthListSupportsExpiryD not expire in Local
Authorization List.
ateTime = true AND
the cacheExpiryDateTime has not
passed
C14.FR.05 Identifier presented is in the Local The Charging Station SHALL send an IdToken will be
Authorization List with a status AuthorizeRequest to try to authorize this IdToken. disregarded, as if not
Accepted AND present in Local
LocalAuthListSupportsExpiryD Authorization List, when
cacheExpiryDateTime
ateTime = true AND
has passed.
the cacheExpiryDateTime has passed

2.5. Use case D LocalAuthorizationList Management

2.5.1. Page 111 - (2024-02) D01 - Send Local Authorization List - Requirements
[745]
Requirement D01.FR.04 incorrectly states that an empty localAuthorizationList can be supplied, but this is not allowed by the JSON
schema.

ID Precondition Requirement definition Note

Old D01.FR.04 If no localAuthorizationList (or an The Charging Station SHALL remove all Note, that the version
empty one) is given and the IdTokens from the list. number of the list is
updateType is Full. still updated to value
of versionNumber in
the request.
New D01.FR.04 If no localAuthorizationList (or an The Charging Station SHALL remove all Note, that the version
empty one) is given and the IdTokens from the list. number of the list is
updateType is Full. still updated to value
of versionNumber in
the request.

2.6. Use Case E Transactions

2.6.1. Page 118 - (2024-02) Clarify that TransactionEvent(Started) requires

chargingState [731]

Page 118 - Clarification for optional fields in TransactionEventRequest

This section explains when to provide a chargingState in the TransactionEventRequest messages, but it did not make explicit that
this also needs to happen in the TransactionEventRequest(eventType = Started) message.

transactionInfo.chargingState
(E02.FR.13) Whenever the charging state changes, the Charging Station must send a TransactionEventRequest containing
chargingState. This implies that a TransactionEventRequest( eventType = Started ) always has a chargingState , because

OCPP 2.0.1 - © Open Charge Alliance 2024 21/145 Edition 2 - Errata 2024-04
 the state goes from non-existent to a value.
If the change of charging state is the only event, then TransactionEventRequest has a triggerReason =
ChargingStateChanged , but if a change in charging state occurs together with other events, such as those represented
by triggerReason CablePluggedIn or (Stop)Authorized , for example, then chargingState can simply be reported as
part of that message.
A TransactionEventRequest with triggerReason = ChargingStateChanged must contain chargingState.

Page 130 - Note in requirement E02.FR.17 is confusing [731]

The note of E02.FR.17 contains to contradicting sentences with respect to combining trigger reasons.

ID Precondition Requirement definition Note

Old E02.FR.17 When a transaction-related trigger The Charging Station SHALL send a When two trigger
event occurs, listed in TransactionEventRequest with a triggerReason reasons overlap, the
TriggerReasonEnumType AND corresponding to the occurred event. more specific one
the transaction is ongoing. should be used. For
example, when a cable
is plugged in,
triggerReason
CablePluggedIn should
be used, not
ChargingStateChanged
.
When two events
occur at the same
time, they need
transmitted using two
separate
TransactionEventRequ
est messages. This is
to prevent information
loss, when something
goes wrong.
New E02.FR.17 When a transaction-related trigger The Charging Station SHALL send a When two trigger
event occurs, listed in TransactionEventRequest with a triggerReason reasons overlap, the
TriggerReasonEnumType AND corresponding to the occurred event. more specific one
the transaction is ongoing. should be used. For
example, when a cable
is plugged in,
triggerReason
CablePluggedIn should
be used, not
ChargingStateChanged
. It is not forbidden to
send separate
TransactionEventRequ
est messages for each
trigger, though.
When two events
occur at the same
time, they need
transmitted using two
separate
TransactionEventRequ
est messages. This is
to prevent information
loss, when something
goes wrong.

2.6.2. Page 147 - (2023-06) Use case E07 - Scenario description step order
incorrect [704]
The Charging Station must first stop the energy transfer as described by step 4, before transmitting the
TransactionEventRequest(eventType = Ended) message from step 2 and 3.

OCPP 2.0.1 - © Open Charge Alliance 2024 22/145 Edition 2 - Errata 2024-04
 No. Type Description
Old text Scenario description 1. The EV Driver presents IdToken a second time to end
TxStopPoint = Authorized (or charging.
PowerPathClosed) 2. The Charging Station sends a TransactionEventRequest
(eventType = Ended) with triggerReason = StopAuthorized
and stoppedReason = Local.
3. The CSMS responds with a TransactionEventResponse.
4. The Charging Station stops the energy transfer and if the
cable is not permanently attached, the Charging Station unlocks
the cable.
New text Scenario description 1. The EV Driver presents IdToken a second time to end
TxStopPoint = Authorized (or charging.
PowerPathClosed) 2. The Charging Station stops the energy transfer and if the
cable is not permanently attached, the Charging Station unlocks
the cable.
3. The Charging Station sends a TransactionEventRequest
(eventType = Ended) with triggerReason = StopAuthorized
and stoppedReason = Local.
4. The CSMS responds with a TransactionEventResponse.

2.6.3. Page 148 - (2023-06) Use case E07: Wrong triggerReason shown in
sequence diagram fig. 56 [687]
The fourth TransactionEventRequest in sequence diagram Figure 56 contains an incorrect triggerReason and should not have an
idToken. Changed to triggerReason = ChargingStateChanged, chargingState = EVConnected.

Figure 56. Sequence Diagram: Transaction locally stopped by IdToken with TransactionEventRequest reported strictly by TxStopPoint
configuration

OCPP 2.0.1 - © Open Charge Alliance 2024 23/145 Edition 2 - Errata 2024-04
 Charging Station CSMS
EV Driver

User authorization successful.

alt [TxStopPoint = Authorized OR TxStopPoint = PowerPathClosed]

TransactionEventRequest(eventType = Ended, transactionId = AB1234, seqNo = N + 1, timestamp,
triggerReason = StopAuthorized, stoppedReason = Local, idToken.id = 1234, meterValues)

TransactionEventResponse(idTokenInfo.status)
[TxStopPoint = EVConnected OR TxStopPoint = ParkingBayOccupancy OR TxStopPoint = EnergyTransfer]
TransactionEventRequest(eventType = Updated, transactionId = AB1234, seqNo = N + 1, timestamp,
triggerReason = StopAuthorized, idToken.id = 1234)

TransactionEventResponse(idTokenInfo.status)

opt [if cable not permanently attached & (same identification or authorized)]
unlock connector

alt [TxStopPoint = EnergyTransfer]

TransactionEventRequest(eventType = Ended, transactionId = AB1234, seqNo = N + 2, timestamp,
triggerReason = ChargingStateChanged, chargingState = EVConnected, stoppedReason = Local, meterValues)

TransactionEventResponse()
[TxStopPoint = EVConnected OR TxStopPoint = ParkingBayOccupancy]
TransactionEventRequest(eventType = Updated, transactionId = AB1234, seqNo = N + 1, timestamp,
triggerReason = ChargingStateChanged, chargingState = EVConnected)

TransactionEventResponse()

Unplug cable

StatusNotificationRequest(Available)

StatusNotificationResponse()

alt [TxStopPoint = EVConnected]

TransactionEventRequest(eventType = Ended, transactionId = AB1234, seqNo = N + 3, timestamp,
triggerReason = EVCommunicationLost, stoppedReason = Local)

TransactionEventResponse()
[TxStopPoint = ParkingBayOccupancy]
TransactionEventRequest(eventType = Updated, transactionId = AB1234, seqNo = N + 3, timestamp,
triggerReason = EVCommunicationLost)

TransactionEventResponse()

Drive out of parking bay

alt [TxStopPoint = ParkingBayOccupancy]

TransactionEventRequest(eventType = Ended, transactionId = AB1234, seqNo = N + 3, timestamp,
triggerReason = EVDeparted, stoppedReason = Local)

TransactionEventResponse()

2.6.4. Page 150 - (2023-06) Use case E07: Clarify 'normal' and 'correct' for
stoppedReason [693]
Some requirements in E07 mention "ended in a normal way" and "set to a correct value", but do not explain what normal and correct
is.

ID Precondition Requirement definition Note

Old text E07.FR.04 If a transaction is ended in a normal The stoppedReason element MAY be e.g. EV-driver presented
way. omitted. IdToken to stop the
transaction.
New text E07.FR.04 If a transaction is stopped on request Charging Station MAY omit the e.g. EV-driver presented
of the EV driver at the Charging stoppedReason element from the IdToken to stop the
Station. final TransactionEventRequest with transaction or pressed a
eventType = Ended "stop" button (not the
emergency stop).
See use case F03 for
remotely stopping.

OCPP 2.0.1 - © Open Charge Alliance 2024 24/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
Old text E07.FR.05 If a transaction is ended in a normal The stoppedReason SHOULD be e.g. EV-driver presented
way assumed 'Local'. IdToken to stop the
transaction.
New text E07.FR.05 If a transaction is stopped on request Charging Station SHOULD use a e.g. EV-driver presented
of the EV driver at the Charging stoppedReason = Local in the final IdToken to stop the
Station. TransactionEventRequest with transaction or pressed a
eventType = Ended. "stop" button (not the
emergency stop).
See use case F03 for
remotely stopping.
Old text E07.FR.06 If the transaction is not ended stoppedReason SHOULD be set to a
normally. correct value.
New text E07.FR.06 If a transaction is stopped, but not on Charging Station SHOULD use the Apart from remotely
request of the EV driver at the most appropriate value from stopping (Remote),
Charging Station. ReasonEnumType for stoppedReason CSMS revoking
in the final TransactionEventRequest authorization
with eventType = Ended. (DeAuthorized) or
disconnecting the EV
(EVDisconnected),
most other reasons are
related to technical
faults or energy
limitations.

Page 403 - TransactionType field stoppedReason

The description for field stoppedReason in TransactionEventRequest has been improved to make clear that this event does not
have to concur with the TransactionEventRequest(Ended) or TxStopPoint, but may have happened some time before.

TransactionType

Field Name Field Type Card. Description

Old stoppedReason ReasonEnumType 0..1 Optional. This contains the reason why the transaction
text was stopped. MAY only be omitted when Reason is
"Local".
New stoppedReason ReasonEnumType 0..1 Optional. The stoppedReason is the reason/event that
text initiated the process of stopping the transaction. It
will normally be the user stopping authorization via
card (Local or MasterPass) or app (Remote), but it
can also be CSMS revoking authorization
(DeAuthorized), or disconnecting the EV when
TxStopPoint = EVConnected (EVDisconnected). Most
other reasons are related to technical faults or energy
limitations.
MAY only be omitted when stoppedReason is "Local"

2.6.5. Page 168 - (2024-04) - E15.FR.04 SessionStopReq ends authorization [757]

Requirement E15.FR.04 states that when Charging Station receives a SessionStopReq from EV this ends the transaction. This
conflicts with the existing mechanism of TxStopPoint to define the end of a transaction. Instead, the requirement is that the
authorization of the transaction is ends when stopping the ISO 15118 session between EV and EVSE. Depending on the value of
TxStopPoint this may also result in ending the transaction (i.e. when TxStopPoint contains Authorized or PowerPathClosed).

The precondition has been added for the case where the user ended authorization on the Charging Station and a
TransactionEvent(StopAuthorized) has already been sent for this before the SessionStopReq arrives.

Updated requirement

OCPP 2.0.1 - © Open Charge Alliance 2024 25/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition
Old E15.FR.04 After receiving a SessionStopReq message from the EV,
the CS SHALL send a TransactionEventRequest message
with eventType = Ended to inform the CSMS that the
charging transaction has been stopped (by the EV).
New E15.FR.04 When TxStopPoint contains Charging Station SHALL send a TransactionEventRequest
"Authorized" or "PowerPathClosed" or message with eventType = Ended and triggerReason =
"EnergyTransfer" AND StopAuthorized and stoppedReason = StoppedByEV
Charging Station has not yet sent a to inform the CSMS that the charging transaction has
TransactionEventRequest with been stopped (by the EV).
triggerReason = StopAuthorized when it
receives a ISO 15118
SessionStopReq(Terminate) message
from the EV

New requirement

ID Precondition Requirement definition

E15.FR.05 When TxStopPoint does not contain Charging Station SHALL send a TransactionEventRequest
"Authorized" or "PowerPathClosed" or message with eventType = Updated and triggerReason =
"EnergyTransfer" AND StopAuthorized to inform the CSMS that the authorization
Charging Station has not yet sent a has ended.
TransactionEventRequest with triggerReason =
StopAuthorized when it receives a ISO 15118
SessionStopReq(Terminate) message from the
EV

2.7. Use Case F Remote Control

2.7.1. Page 180 - (2023-06) Requirement F03.FR.03 contains wrong precondition

[700]
The precondition of requirement F03.FR.03 was incorrectly merged from Errata v2 into Edition 2, and the associated Note was not
relevant for this situation.
It needs to be changed as follows:

Changed requirement

ID Precondition Requirement definition Note

Old text F03.FR.03 F03.FR.01 AND The Charging Station SHALL send a For example when
TxStopPoint configuration causes TransactionEventRequest (eventType = Ended, TxStopPoint =
transaction to end (E.g. triggerReason = RemoteStop, stoppedReason EVConnected and EV
TxStopPoint is NOT Authorized = Remote) to the CSMS. is disconnected after
or PowerPathClosed) the
RequestStopTransacti
onRequest.
New text F03.FR.03 F03.FR.01 AND The Charging Station SHALL send a For example when
TxStopPoint configuration causes TransactionEventRequest (eventType = Ended, TxStopPoint =
transaction to end (E.g. triggerReason = RemoteStop, stoppedReason EVConnected and EV
TxStopPoint is NOT Authorized = Remote) to the CSMS. is disconnected after
or PowerPathClosed) the
RequestStopTransacti
onRequest.

2.7.2. Page 187 - (2023-06) Requirement F06.FR.12 is too strict [707]

Requirement F06.FR.12 explicitly tells a Charging Station to reject a TriggerMessageRequest for a requestedMessage
StatusNotification without evse or evse.connectorId. There is no need to require this from a Charging Station, since F06.FR.13
already mandates that CSMS shall provide an evse.connectorId (and an evse.id, because that is mandatory in the evse object) in
this message.

The requirement definition of F06.FR.12 has been relaxed from SHALL to a MAY, so that a Charging Station implementation that is

OCPP 2.0.1 - © Open Charge Alliance 2024 26/145 Edition 2 - Errata 2024-04
able to handle to a request without evse.connectorId and an implementation that rejects this, are both allowed, since a CSMS is not
allowed to send a request without evse_connectorId.

Changed requirement

ID Precondition Requirement definition Note

Old text F06.FR.12 If a Charging Station receives a The Charging Station SHALL respond with a StatusNotification
TriggerMessageRequest with TriggerMessageResponse with status messages can only be
requestedMessage set to: Rejected. sent at connector
StatusNotification AND level.
( evse is omitted OR
evse.connectorId is omitted )
New text F06.FR.12 If a Charging Station receives a The Charging Station MAY respond with a StatusNotification
TriggerMessageRequest with TriggerMessageResponse with status messages can only be
requestedMessage set to: Rejected. requested at
StatusNotification AND connector level.
( evse is omitted OR
evse.connectorId is omitted )

2.7.3. Page 187 - (2024-02) Improved precondition of F06.FR.06/07 [719]

Requirements F06.FR.06/07 use the word "receive" in precondition, but it only applies when the message is accepted. F06.FR.05
allows for the possibility that a Charging Station does not accept the message, in which case F06.FR.06/07 do not apply.

Updated requirements

ID Precondition Requirement definition Note

Old F06.FR.06 If a Charging Station receives a The Charging Station SHALL send a
TriggerMessageRequest with MeterValuesRequest to the CSMS with the
requestedMessage set to: most recent measurements for all measurands
MeterValues configured in Configuration Variable:
AlignedDataMeasurands.
New F06.FR.06 If a Charging Station accepts a The Charging Station SHALL send a
TriggerMessageRequest with MeterValuesRequest to the CSMS with the
requestedMessage set to: most recent measurements for all measurands
MeterValues configured in Configuration Variable:
AlignedDataMeasurands.
Old F06.FR.07 If a Charging Station receives a The Charging Station SHALL send a
TriggerMessageRequest with TransactionEventRequest to the CSMS with
requestedMessage set to: triggerReason = Trigger, transactionInfo with at
TransactionEvent least the chargingState, and meterValue with
the most recent measurements for all
measurands configured in Configuration
Variable:
SampledDataTxUpdatedMeasurands.
New F06.FR.07 If a Charging Station accepts a The Charging Station SHALL send a
TriggerMessageRequest with TransactionEventRequest to the CSMS with
requestedMessage set to: triggerReason = Trigger, transactionInfo with at
TransactionEvent least the chargingState, and meterValue with
the most recent measurements for all
measurands configured in Configuration
Variable:
SampledDataTxUpdatedMeasurands.

2.8. Use Case G Availability

2.8.1. Page 192 - (2023-06) G01.FR.08 contradicts H01.FR.24 [692]

Requirement G01.FR.08 states that a StatusNotification must be sent when a connector becomes reserved. However, this topic is
already covered in use case H01 in a slightly different way. Therefore, the "becomes reserved" must be removed from G01.FR.08
and left to H01.FR.24.

Table 2. G01 - Requirements

OCPP 2.0.1 - © Open Charge Alliance 2024 27/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition
Old text G01.FR.08 When a connector of an EVSE becomes The Charging Station SHOULD NOT send a
reserved or a cable is plugged-in AND StatusNotificationRequest for the other connector(s),
The EVSE has multiple connectors even though they are no longer usable.

New text G01.FR.08 When a cable is plugged in to a connector The Charging Station SHOULD NOT send a
of an EVSE AND StatusNotificationRequest for the other connector(s),
The EVSE has multiple connectors even though they are no longer usable.

2.8.2. Page 196 - (2024-02) G03.FR.03/04 improved [750]

It was not clear from requirement G03.FR.03 that this also applied the a change of Connector state. This is now made explicit.

Sending a StatusNotificationRequest is only required for changes in Connector status, as is mentioned in Note 2 under the table.
This has been added to the precondition of G03.FR.04 for completeness.

Updated requirements

G03 - Requirements

ID Precondition Requirement definition Note

Old G03.FR.03 In the event that CSMS requests The Charging Station SHALL respond with
the Charging Station to change an availability status Accepted.
EVSE to the state it is already in.
New G03.FR.03 In the event that CSMS requests The Charging Station SHALL respond with
the Charging Station to change an availability status Accepted.
EVSE or Connector to the state it is
already in.
Old G03.FR.04 When an availability change The Charging Station SHALL inform the CSMS As described in
request with of its new availability status with ChangeAvailabilityStat
ChangeAvailabilityRequest has StatusNotificationRequest. usEnumType
happened.
New G03.FR.04 When an availability change The Charging Station SHALL inform the CSMS As described in
request with of its new Connector availability status with ChangeAvailabilityStat
ChangeAvailabilityRequest has StatusNotificationRequest. usEnumType
changed the state of a Connector .

2.9. Use Case H Reservation

2.9.1. Page 205 - (2023-06) Missing option to send NotifyEvent instead of

StatusNotification [699]
Instead of StatusNotificationRequest it is also allowed to send a NotifyEvent(AvailabilityState) for the connector, which will become
the preferred method in future OCPP releases. This option was missing from use case H and is added to the following
requirements.

Changed requirements

ID Precondition Requirement definition Note

Old text H01.FR.20 H01.FR.04 The Charging Station SHALL send a If an EVSE is reserved,
StatusNotificationRequest with all of its connectors
AND
connectorStatus = Reserved for all are reported as
amount of EVSEs available equals
connectors of the EVSE. reserved.
the amount of reservations
New text H01.FR.20 H01.FR.04 The Charging Station SHALL send for all If an EVSE is reserved,
connectors of the EVSE: all of its connectors
AND
are reported as
amount of EVSEs available equals - a StatusNotificationRequest with
reserved.
the amount of reservations connectorStatus = Reserved, OR
- a NotifyEventRequest with component =
"Connector", variable = "AvailabilityState",
trigger = "Delta", actualValue = "Reserved"

OCPP 2.0.1 - © Open Charge Alliance 2024 28/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
Old text H01.FR.23 If the Charging Station receives a The Charging Station SHALL respond with a If an EVSE is reserved,
ReserveNowRequest for evseId ReserveNowResponse with status Accepted all of its connectors
AND this EVSE is Available AND SHALL send a StatusNotificationRequest are reported as
with connectorStatus = Reserved for all reserved.
connectors of the EVSE.
New text H01.FR.23 If the Charging Station receives a The Charging Station SHALL respond with a If an EVSE is reserved,
ReserveNowRequest for evseId ReserveNowResponse with status Accepted all of its connectors
AND this EVSE is Available AND SHALL send for all connectors of the are reported as
EVSE: reserved.
- a StatusNotificationRequest with
connectorStatus = Reserved, OR
- a NotifyEventRequest with component =
"Connector", variable = "AvailabilityState",
trigger = "Delta", actualValue = "Reserved"
Old text H01.FR.24 H01.FR.06 The Charging Station SHALL send a If an EVSE is reserved
StatusNotificationRequest with for a specific
AND
connectorStatus = Reserved for all connectorType, all
amount of reservations for a
connectors of the EVSEs with the specific connectors on the
specific connectorType equals the
connectorType. EVSE are reported as
amount of available EVSEs with
reserved.
that specific connectorType
New text H01.FR.24 H01.FR.06 The Charging Station SHALL send for all If an EVSE is reserved
connectors of the EVSEs that have the for a specific
AND
specific connectorType connectorType, all
amount of reservations for a
- a StatusNotificationRequest with connectors on the
specific connectorType equals the
EVSE are reported as
amount of available EVSEs with connectorStatus = Reserved, OR
reserved.
that specific connectorType - a NotifyEventRequest with component =
"Connector", variable = "AvailabilityState",
trigger = "Delta", actualValue = "Reserved"

Page 203 - (2023-06) Added option to use case description to send NotifyEventRequests
Use case H01 scenario S2 only mentions StatusNotificationRequests, but the use of NotifyEventRequests is also allowed. This has
been added in bold, similarly to how this was done in use case G01 StatusNotification.

S2 Scenario objective Reserve a specific EVSE at a Charging Station

Scenario description 1. EV Driver asks the CSMS to reserve a specific EVSE at the Charging Station.
2. The CSMS sends ReserveNowRequest with a EVSE to a Charging Station.
3. Upon receipt of ReserveNowRequest, the Charging Station responds with
ReserveNowResponse with status Accepted.
4. The Charging Station sends StatusNotificationRequest with the status Reserved for all
Connectors of that EVSE.
5. The CSMS responds with StatusNotificationResponse to the Charging Station.
Alternative scenario Steps 1, 2 and 3 as above.
description 4. Instead of a StatusNotificationRequest a Charging Station can send a NotifyEventRequest
with trigger = Delta for component.name = "Connector" and the EVSE number in evse.id and the
connector number in evse.connectorId, variable = "AvailabilityState" and actualValue =
"Reserved".
5a. Optionally, Charging Station can also report a NotifyEventRequest for component = "EVSE",
variable = "AvailabilityState" and actualValue = "Reserved" , and when applicable, also report this
for component = "ChargingStation".
Prerequisite(s) The specified EVSE of the Charging Station has status Available
Postcondition(s) Successful postcondition:
The Charging Station has accepted the ReserveNowRequest
AND
sent StatusNotificationRequests with status Reserved.
Failure postcondition:
The Charging Station has rejected the ReserveNowRequest
OR
The Charging Station has NOT sent StatusNotificationRequests with status Reserved.

OCPP 2.0.1 - © Open Charge Alliance 2024 29/145 Edition 2 - Errata 2024-04
2.9.2. Page 209 - (2023-06) Remark about authorization in use case H03 [711]
Use case H01 has a remark that says: "It is RECOMMENDED to validate the Identifier with an AuthorizeRequest after reception of
ReserveNowRequest and before the start of the transaction." Use case H03 about using a reservation does not have a
recommendation to validate before starting the transaction.

In order to be consistent with H01, this has been added to the remark of H03, as shown in bold:

7 Error handling n/a

8 Remark(s) It is RECOMMENDED to validate the Identifier with an AuthorizeRequest after reception of
ReserveNowRequest and before the start of the transaction.

2.9.3. Page 210 - (2023-06) Requirement H03.FR.08 is not clear about

groupIdToken lookup [684]
Requirement H03.FR.08 can mistakenly be interpreted as having to look up the groupIdToken in the Local Authorization List or
Authorization Cache. However, the intention is to look up the incoming idToken to get its associated groupIdToken, if any.

The requirements H03.FR.07 and H03.FR.08 exist to make clear, that for a reserved EVSE or connector a lookup or authorize
request for idToken is needed when a groupIdToken is involved.

Changed requirement

ID Precondition Requirement definition

Old text H03.FR.08 H03.FR.07 AND The Charging Station SHALL send an AuthorizeRequest
If it is not found in the Local Authorization for the incoming IdToken to the CSMS in order to get its
List or Authorization Cache. associated groupIdToken.

New text H03.FR.08 H03.FR.07 AND The Charging Station SHALL send an AuthorizeRequest
If the incoming IdToken is not found in the for the incoming IdToken to the CSMS in order to get its
Local Authorization List or Authorization associated groupIdToken.
Cache. (Note: This AuthorizeRequest may already have been
performed when the idToken was presented for
authorization.)

2.9.4. Page 210 - (2023-12) Transaction can start even when connector is
Reserved [735]
It is not sufficiently clear from use case H03 that a transaction on a reserved connector will be started at the time of cable plug-in
or occupancy of parking bay when TxStartPoint is EVConnected or ParkingBayOccupancy. However, only the IdToken (or
groupIdToken) that matches the reservation can be authorized. Non-reserved IdTokens will therefore not be able to charge.

This is clarified by adding the following requirements:

Page 210 - H03

New requirement

ID Precondition Requirement definition

H03.FR.09 When an idToken or groupIdToken is presented Charging Station SHALL consider the reservation to be used
that matches a reservation (consumed)
H03.FR.10 H03.FR.09 AND Charging Station SHALL set connector status to Available if
Connector associated with reservation has no cable has been plugged-in, or Occupied if a cable has
status Reserved already been plugged-in.

Page 196 - G03

New requirement

OCPP 2.0.1 - © Open Charge Alliance 2024 30/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
G03.FR.09 The connector is Reserved when an Connector status SHALL not change. Connector stays
EV is connecting AND reserved until IdToken
EV driver has not presented an matching reservation is
IdToken matching the reservation presented or reservation
expires.

2.10. Use Case J Meter Values

2.10.1. Page 224 - (2024-04) 2.2. Clock-Aligned Meter Values: additional note
[746]
At the end of section 2.2 add the following note:

Clock-aligned meter values for an EVSE that is involved in a transaction MAY be transmitted in
NOTE
TransactionEventRequests with context = Sample.Clock instead of in MeterValuesRequests.

2.10.2. Page 225 - (2024-04) New section: 2.5 Configuration Examples [746]
Below are a few examples of configurations for transaction-related measurands:

Only sampled energy register values for start/stop at end of transaction

• SampledDataCtrlr.TxStartedMeasurands and TxUpdatedMeasurands are left empty.
• SampledDataCtrlr.TxEndedMeasurands = "Energy.Active.Import.Register"
• SampledDataCtrlr.TxEndedInterval = 0

Values of energy register at start, during and end of transaction

• SampledDataCtrlr.TxStartedMeasurands = "Energy.Active.Import.Register"
• SampledDataCtrlr.TxUpdatedMeasurands = "Energy.Active.Import.Register"
• SampledDataCtrlr.TxUpdatedInterval = 300 (every 5 minutes)
• SampledDataCtrlr.TxEndedMeasurands = "Energy.Active.Import.Register"
• SampledDataCtrlr.TxEndedInterval = 0

Only clock-aligned register values during and start/stop at end of transction

• SampledDataCtrlr.TxStartedMeasurands and TxUpdatedMeasurands are left empty.
• SampledDataCtrlr.TxEndedMeasurands = "Energy.Active.Import.Register"
• SampledDataCtrlr.TxEndedInterval = 0
• AlignedDataCtrlr.Measurands = "Energy.Active.Import.Register"
• AlignedDataCtrlr.Interval = 300 (every 5 minutes)

2.10.3. Page 227 - (2024-04) J01.FR.14 Improved requirements for clock-aligned

values
The precondition for J01.FR.14 has been made more specific to improve clarity.

Changed requirement

OCPP 2.0.1 - © Open Charge Alliance 2024 31/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
Old J01.FR.14 When configured to send The Charging Station SHALL send It is allowed to report
MeterValuesRequest, See: Meter MeterValuesRequest messages to the CSMS the measurands for
Values - Configuration as configured in Meter Values - Configuration, EVSEs with an ongoing
for all evseIds, locations and phases for which transaction using the
a configured measurand is supported. TransactionEventRequ
est message.
It is possible that
certain measurands
are not available for
every location. For
example, evseId = 0
(grid meter) will not
have a
"Current.Offered" or
"SoC" measurand.
New J01.FR.14 When AlignedDataCtrlr.Interval > 0 The Charging Station SHALL send a It is possible that
AND MeterValuesRequest message to the CSMS certain measurands
EVSE for which measurands are for the measurands in are not available for
sent, is not involved in a AlignedDataCtrlr.Measurands at every every location. For
transaction AlignedDataCtrlr.Interval for all evseIds , example, evseId = 0
locations and phases for which a configured (grid meter) will not
measurand is supported. have a
"Current.Offered" or
"SoC" measurand.
See also J01.FR.22

A new requirement has been added to make clear that meter values for an EVSE that is involved in a transaction can also be sent in
a TransactionEventRequest.

New requirement

ID Precondition Requirement definition Note

J01.FR.22 When AlignedDataCtrlr.Interval > 0 The Charging Station SHALL send either: See also J01.FR.14
AND - a MeterValuesRequest message or
EVSE for which measurands are sent, - a TransactionEventRequest with triggerReason =
is involved in a transaction
Sample.Clock
to the CSMS for the measurands in
AlignedDataCtrlr.Measurands at every
AlignedDataCtrlr.Interval.

2.10.4. Page 228 - (2023-06) Requirement J01.FR.14 is unclear that meter values
for all EVSEs must be sent [674]
J01 is not clear about the fact that MeterValuesRequest for clock-aligned data always need to be sent for all locations, including
the grid energy meter, which is designated by evseId = 0. It is stated in the text in par. 2.3: "When a Charging Station can measure
the same measurand on multiple locations or phases, all possible locations and/or phases SHALL be reported when configured in
one of the relevant Configuration Variables." The requirement J01.FR.14 has been extended to refer to all possible locations and
phases.

Changed requirement

ID Precondition Requirement definition Note

Old text J01.FR.14 When configured to The Charging Station SHALL send
send MeterValuesRequest messages to the CSMS
MeterValuesRequest, as configured.
See: Meter Values -
Configuration

OCPP 2.0.1 - © Open Charge Alliance 2024 32/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
New text J01.FR.14 When configured to The Charging Station SHALL send It is allowed to report the
send MeterValuesRequest messages to the CSMS measurands for EVSEs with an
MeterValuesRequest, as configured in Meter Values - Configuration, ongoing transaction using the
See: Meter Values - for all evseIds, locations and phases for which TransactionEventRequest
Configuration a configured measurand is supported. message.
It is possible that certain
measurands are not available for
every location. For example,
evseId = 0 (grid meter) will not
have a "Current.Offered" or "SoC"
measurand.

2.10.5. Page 230 - (2023-06) Requirement J02.FR.10 refers to all

TransactionEventRequest messages, but should be specific to only eventType =
Updated [705]
A TransactionEventRequest(Started/Update) should only have sampled values that are part of the same sampling interval. Ideally,
this would mean that all sampled values have the same timestamp, and can thus be part of a single meterValue element. In
practice, however, when multiple measurands or meters are sampled the associated timestamps may differ slightly. This is
acceptable, as long as the samples belong to the same sampling interval.

This was the intention of J02.FR.10 with the phrase "belong to the timestamp in the message", but it could also be interpreted as
requiring identical timestamps. Also, it forgot to mention that it only applies to Started and Updated events, since an Ended event
can contain metervalues for multiple timestamps.

Changed requirement

ID Precondition Requirement definition Note

Old text J02.FR.10 The meterValue measurements in the same meterValues for other timestamps
TransactionEventRequest message SHALL all should be sent in separate
belong to the timestamp in the message TransactionEventRequest
messages.
New text J02.FR.10 If a All meterValue elements SHALL have a Only for eventType = Ended can a
TransactionEventRequ timestamp that is within the current sampling TransactionEventRequest have
est message with interval, i.e.: meter values for multiple
eventType = Started (transaction event timestamp - intervals.
or eventType = Update SampledDataTxUpdatedInterval) <
contains multiple meterValue.timestamp <= transaction event
meterValue elements, timestamp
rather than one
meterValue with one
or more sampledValue
elements

2.10.6. Page 230 - (2024-04) J02.FR.11 Improved requirements for sampled

values
ID Precondition Requirement definition Note
Old J02.FR.11 When configured to send meter The Charging Station SHALL send a
data in the TransactionEventRequest(eventType =
TransactionEventRequest(eventTy Updated with triggerReason =
pe = Updated) AND MeterValuePeriodic with the configured
When the interval in measurands in the meterValue field.
SampledDataTxUpdatedInter
val has elapsed
(See: Meter Values - Configuration
)

OCPP 2.0.1 - © Open Charge Alliance 2024 33/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
New J02.FR.11 When The Charging Station SHALL send a See E01 for sending of
SampledDataTxUpdatedInter TransactionEventRequest(eventType = SampledDataCtrlr.TxSt
val > 0 Updated with triggerReason = artedMeasurands and
MeterValuePeriodic with the measurands E06 for
configured in SampledDataCtrlr.TxE
SampledDataCtrlr.TxUpdatedMeasurands in ndedMeasurands.
the meterValue field at every
SampledDataCtrlr.TxUpdatedInterval.

2.10.7. Page 231 - (2023-06) J01 misses requirement that meter value must be for
current transaction [673]
It is perhaps obvious, but not stated anywhere. Transaction-related meter values reported in the TransactionEventRequest must
only report the measurand(s) associated with the evse of the TransactionEventRequest.

New requirement

ID Precondition Requirement definition Note

J02.FR.22 Meter values reported in a
TransactionEventRequest message SHALL all be
related to EVSE on which the transaction is taking
place.

2.11. Use Case K Smart Charging

2.11.1. Page 238 - (2023-06) Text in section 3.3 does not match
ChargingProfileKindEnumType description [708]
The description of the ChargingProfileKindEnumType Relative was updated in Edition 2 to be more exact. This update was
unfortunately not performed in section 3.3 Charging Profile Recurrency that introduces the charging profile kinds.

Below is the updated text shown in bold:

ChargingProfile Description
Kind
Old text Relative Charging schedule periods start when ChargingProfile is activated. In most cases this will
be at start of the power delivery. When a ChargingProfile is received for a transaction in
progress, then it should activate immediately. No value for startSchedule should be
supplied.
New text Relative Charging schedule periods should start when the EVSE is ready to deliver energy. i.e.
when the EV driver is authorized and the EV is connected. When a ChargingProfile is
received for a transaction that is already charging, then the charging schedule periods
should remain relative to the PowerPathClosed moment.
No value for startSchedule should be supplied.

2.11.2. Page 245 - (2024-04) - K01.FR.29 also accepts NotImplemented [755]

Requirement K01.FR.29 expects NotSupported to be returned when smart charging is not supported. If smart charging is not
supported at all, it is likely that they complete message is not implemented. In that case returning a CALLERROR NotImplemented
is allowed according to Part 4 chapter 4.3.

ID Precondition Requirement definition Note

Old K01.FR.29 When Charging Station Charging Station SHALL respond with RPC
does not support smart Framework CALLERROR: NotSupported.
charging.
New K01.FR.29 When Charging Station Charging Station SHALL respond with RPC
does not support smart Framework CALLERROR: NotSupported or
charging. NotImplemented .

OCPP 2.0.1 - © Open Charge Alliance 2024 34/145 Edition 2 - Errata 2024-04
2.11.3. Page 274 - (2024-02) Transactions for ISO15118 do not support
TxStartPoints EnergyTransfer/DataSigned [763]
With ISO15118 a charging profile is exchanged before energy transfer. This is a TxProfile (K15.FR.07) and therefore a transaction
must already exist before energy transfer is signed.

As a result TxStartPoints EnergyTransfer and DataSigned cannot be supported. The prerequisite of use cases K15 needs to be
updated for this.

Old 7 Prerequisites Both the Charging Station and the EV support ISO 15118.
New 7 Prerequisites Both the Charging Station and the EV support ISO 15118. The configured TxStartPoint
needs to contain at least one of ParkingBayOccupied, EVConnected, Authorized or
PowerPathClosed, such that the OCPP transaction is started before
ChargeParameterDiscoverReq is sent by EV, such that CSMS can send a TxProfile charging
profile.

2.11.4. Page 276 - (2023-12) Requirement K15.FR.15 has wrong precondition

[716]
Requirement K15.FR.15 should refer to the moment when EV sends charging needs, which is K15.FR.01.

ID Precondition Requirements Note

Old K15.FR.1 K15.FR.03 The Charging Station SHALL use the
5 TxDefaultProfile (if present) and generate
AND
a charging schedule within the limits of its
Charging Station is
composite schedule.
offline
New K15.FR.1 K15.FR.01 The Charging Station SHALL use the
5 TxDefaultProfile (if present) and generate
AND
a charging schedule within the limits of its
Charging Station is
composite schedule.
offline

2.12. Use Case L FirmwareManagement

2.12.1. Page 287 - (2023-06) Improved title of figure 119 [695]

Figure 119 shows the transitions between all FirmwareStatusEnumType values. As such, it is a state transition diagram. The title,
however, calls it "Firmware update process", which is not correct, because it does not cover all steps for performing a firmware
update.

Old text Figure 119. Firmware update process

New text Figure 119. Firmware status transitions

2.12.2. Page 288 - (2024-02) L01 InstallScheduled when waiting for transaction
[729]
Requirement L01.FR.16 states that a FirmwareStatusNotificationRequest with status = InstallScheduled must be sent when
installDateTime is set to a time in the future. The option is missing, however, to send a InstallScheduled status when waiting
with installation until a transaction has finished, wheresas a simlar situation for DownloadScheduled when waiting until a
transaction has finished is explicitly mentioned in L01.FR.13.

A new "MAY" requirement has been added to allow sending an InstallScheduled status in such a case.

New requirement for L01

OCPP 2.0.1 - © Open Charge Alliance 2024 35/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
L01.FR.34 L01.FR.04 AND The Charging Station MAY send a The case where
FirmwareStatusNotificationRequest with status installDateTime is set is
installDateTime is not set AND
InstallScheduled. covered by L01.FR.16.
Charging Station is waiting for a
transaction to finish

2.12.3. Page 292 - (2024-02) L02 InstallScheduled when waiting for transaction
[729]
This is a similar change in L02 as in Page 288 - (2024-02) L01 InstallScheduled when waiting for transaction [729] for the same
reason.

A new "MAY" requirement has been added to allow sending an InstallScheduled status when waiting for a transaction to finsh.

New requirement for L02

ID Precondition Requirement definition Note

L02.FR.23 When the Charging Station has The Charging Station MAY send a The case where
successfully downloaded the firmware FirmwareStatusNotificationRequest with status installDateTime is set is
AND InstallScheduled. covered by L02.FR.10.
installDateTime is not set AND
Charging Station is waiting for a
transaction to finish

2.12.4. Page 288/292 - (2024-02) Add support for A/B firmware updates
Certain types of Charging Stations support downloading and installing the new firmware while transactions are still ongoing, but
need to wait for the transactions to end before activating the firmware by an automatic reboot.

A new requirement has been added for use case L01 and L02.

New requirements

ID Precondition Requirement definition Note

L01.FR.33 L01.FR.05 The Charging Station SHALL wait until all E.g. in case of A/B
transactions have ended, before activating the firmware updates.
AND
installed firmware.
The Charging Station has ongoing
transactions
AND
a reboot is needed to activate the
installed firmware
L02.FR.22 L02.FR.02 The Charging Station SHALL wait until all E.g. in case of A/B
transactions have ended, before activating the firmware updates.
AND
installed firmware.
The Charging Station has ongoing
transactions
AND
a reboot is needed to activate the
installed firmware

Updated requirement precondition

OCPP 2.0.1 - © Open Charge Alliance 2024 36/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
Old text L01.FR.06 L01.FR.05 The Charging Station SHALL wait until all
transactions have ended, before commencing
AND
installation.
The Charging Station has ongoing
transactions
AND
When it is not possible to continue
charging during installation of
firmware
New text L01.FR.06 L01.FR.05 The Charging Station SHALL wait until all
transactions have ended, before commencing
AND
installation.
The Charging Station has ongoing
transactions
AND
When it is not possible to start
installation of firmware while a
transaction is ongoing
Old text L02.FR.03 L02.FR.02 The Charging Station SHALL wait until all
transactions have ended, before commencing
AND
installation.
The Charging Station has ongoing
transactions
AND
When it is not possible to continue
charging during installation of
firmware
New text L02.FR.03 L02.FR.02 The Charging Station SHALL wait until all
transactions have ended, before commencing
AND
installation.
The Charging Station has ongoing
transactions
AND
When it is not possible to start
installation of firmware while a
transaction is ongoing

Updated requirement precondition

ID Precondition Requirement definition Note

Old text L01.FR.07 L01.FR.06 AND The Charging Station SHALL set all connectors
configuration variable that are not in use to UNAVAILABLE while the
AllowNewSessionsPendingFi Charging Station waits for the ongoing
rmwareUpdate is false or does transactions to end. Until the firmware is
not exist installed, any connector that becomes
available SHALL be set to UNAVAILABLE.
New text L01.FR.07 L01.FR.06 or L01.FR.33 AND The Charging Station SHALL set all EVSEs that
configuration variable are not in use to UNAVAILABLE while the
AllowNewSessionsPendingFi Charging Station waits for the ongoing
rmwareUpdate is false or does transactions to end. Until the firmware is
not exist installed, any EVSE that becomes available
SHALL be set to UNAVAILABLE.
Old text L02.FR.04 L02.FR.03 AND The Charging Station SHALL set all connectors
configuration variable that are not in use to UNAVAILABLE while the
AllowNewSessionsPendingFi Charging Station waits for the ongoing
rmwareUpdate is false or does transactions to end. Until the firmware is
not exist installed, any connector that becomes
available SHALL be set to UNAVAILABLE.
New text L02.FR.04 L02.FR.03 or L02.FR.22 AND The Charging Station SHALL set all EVSEs that
configuration variable are not in use to UNAVAILABLE while the
AllowNewSessionsPendingFi Charging Station waits for the ongoing
rmwareUpdate is false or does transactions to end. Until the firmware is
not exist installed, any EVSE that becomes available
SHALL be set to UNAVAILABLE.

OCPP 2.0.1 - © Open Charge Alliance 2024 37/145 Edition 2 - Errata 2024-04
Updated requirement definition

Requirement L02.FR.21 was previously updated, but matching requirement L01.FR.32 was forgotten. Requirement L01.FR.32 is
now updated with a better description and L02.FR.21 is updated to match this description.

ID Precondition Requirement definition Note

Old L01.FR.32 When a Charging Station needs to The Charging Station MAY send a
reboot before activating the FirmwareStatusNotificationRequest with
downloaded firmware status InstallRebooting, before rebooting.
New L01.FR.32 When a Charging Station has The Charging Station SHALL either: Option (a) is preferred,
successfully installed the new (a) send an optional because it notifies
firmware AND FirmwareStatusNotificationRequest with CSMS of an upcoming
the Charging Station needs to status = InstallRebooting before reboot of the Charging
reboot before activating the new rebooting and send a mandatory Station, and the final
firmware FirmwareStatusNotificationRequest with status = Installed is
status = Installed by the newly activated sent by the new
firmware image, so
firmware, or
that CSMS can be sure
(b) only send a
that the new firmware
FirmwareStatusNotificationRequest with
is active. This is not
status set to Installed without reporting the
guaranteed by option
reboot and activation of the new firmware.
(b) when rebooting of
the new firmware
could fail.

Requirement L02.FR.21 is now phrased the same as L01.FR.32.

ID Precondition Requirement definition Note

Old L02.FR.21 When the Charging Station has The Charging Station SHALL send a It is optional to report
successfully installed the new FirmwareStatusNotificationRequest with the
firmware AND status set to Installed or preferably to FirmwareStatusNotific
the Charging Station needs to InstallRebooting and report another ationRequest with
reboot before activating the new FirmwareStatusNotificationRequest with status
firmware status Installed after the new firmware has InstallRebooting,
been activated. however if it is
deemed necessary to
report to the CSMS
that the Charging
Station succeeded in
installing the new
firmware, but needs to
reboot before being
able to activate the
new firmware, it is
recommended to use
status InstallRebooting
for this.
New L02.FR.21 When the Charging Station has The Charging Station SHALL either: Option (a) is preferred,
successfully installed the new (a) send an optional because it notifies
firmware AND FirmwareStatusNotificationRequest with CSMS of an upcoming
the Charging Station needs to status = InstallRebooting before reboot of the Charging
reboot before activating the new rebooting and send a mandatory Station, and the final
firmware FirmwareStatusNotificationRequest with status = Installed is
status = Installed by the newly activated sent by the new
firmware image, so
firmware, or
that CSMS can be sure
(b) only send a
that the new firmware
FirmwareStatusNotificationRequest with
is active. This is not
status set to Installed without reporting the
guaranteed by option
reboot and activation of the new firmware.
(b) when rebooting of
the new firmware
could fail.

OCPP 2.0.1 - © Open Charge Alliance 2024 38/145 Edition 2 - Errata 2024-04
2.12.5. Page 289 - (2024-02) Allow DownloadFailed/InstallationFailed when
AcceptedCanceled [733]
When a firmware update is overruled by a new FirmwareUpdateRequest it is allowed (but not required) to report a
FirmwareStatusNotification(DownloadFailed/InstallationFailed) (depending on where it was in its update process) for the
firmware update that has now been canceled.

The note to requirement L01.FR.24 has been updated to reflect this.

ID Precondition Requirement definition Note

L01.FR.24 When a Charging Station is installing The Charging Station SHOULD cancel the ongoing The Charging Station
new Firmware OR firmware update AND respond with status SHOULD NOT first check
is going to install new Firmware, but AcceptedCanceled. if the new firmware file
has received an UpdateFirmware exists, this way the
command to install it at a later time CSMS will be able to
cancel an ongoing
AND
firmware update without
the Charging Station receives a new
UpdateFirmwareRequest starting a new one.
The Charging Station
may send a
FirmwareStatusNotificati
onRequest with status
DownloadFailed or
InstallationFailed
for the firmware update
that has now been
canceled.

2.13. Use Case M ISO 15118 CertificateManagement

2.13.1. Page 310 - (2023-06) M04.FR.07 has an incorrect requirement definition

[703]
Requirement M04.FR.07 mentions a hash algorithm used during installation, but no hash algorithm is used to install a certificate.
The intention of this requirement was, as is suggested by the note, that the CSMS, when deleting a certificate, uses the same
hashAlgorithm as the Charging Station when generating the certificateHashData for a certificate.

ID Precondition Requirement definition Note

Old text M04.FR.07 When deleting a certificate The CSMS SHALL use the hashAlgorithm, When a new firmware
which was used to install the certificate. is installed it is
RECOMMENDED that
the CSMS requests the
certificate first using
GetInstalledCertificateI
dsRequest to be sure
of the used
hashAlgorithm.
New text M04.FR.07 When deleting a certificate The CSMS SHALL use the same This ensures CSMS
hashAlgorithm as the Charging Station uses to uses a hashAlgorithm
report the certificateHashData for the that is supported by
certificate in the the Charging Station.
GetInstalledCertificateIdsResponse.

2.14. Use Case N Diagnostics

2.14.1. Page 317 - (2023-06) N01.FR.10 not clear when to report UploadFailure
[696]
Requirement N01.FR.10 does not make clear whether the LogStatusNotification about failure to upload should be sent after all retry
attempts or at each failure. Both options are allowed, but it is recommended to do this after all retry attempts have failed. This has
been added to the note.

OCPP 2.0.1 - © Open Charge Alliance 2024 39/145 Edition 2 - Errata 2024-04
 ID Precondition Requirement definition Note
Old text N01.FR.10 When uploading a log document The Charging Station SHALL send a It is RECOMMENDED
failed LogStatusNotificationRequest with status to send a status that
UploadFailure, BadMessage, PermissionDenied describes the reason
OR NotSupportedOperation. of failure as precise as
possible.
New text N01.FR.10 When uploading a log document The Charging Station SHALL send a It is RECOMMENDED
failed LogStatusNotificationRequest with status to send the status only
UploadFailure, BadMessage, after all retry attempts
PermissionDenied OR have failed.
NotSupportedOperation. A Charging Station
MAY send a new
Uploading status
upon each retry
attempt.

2.14.2. Page 331 - (2023-06) Requirement N09.FR.04 has been rephrased [688]
Requirement N09.FR.04 for CSMS states that a reference to a customer by either idToken, customerCertificate or customerIdentifier
is needed, but it does not tell what to do if that is not obeyed.

A new requirement has been added for Charging Station for this case.

New requirement

ID Precondition Requirement definition Note

N09.FR.09 When CustomerInformationRequest Charging Station SHALL respond with status = Only one value for either
contains none of idToken, Invalid idToken,
customerCertificate or customerCertificate or
customerIdentifier OR customerIdentifier may
CustomerInformationRequest be provided.
contains more than one of idToken, Charging Station
customerCertificate or counterpart requirement
customerIdentifier of N09.FR.04.

2.15. Messages

2.15.1. Page 353 - (2023-06) Clarification for use of certificate and

iso15118CertificateHashData in AuthorizeRequest [675]
In case of ISO 15118 Plug&Charge the AuthorizeRequest has two optional fields: certificate and iso15118CertificateHashData. The
behaviour is described in requirements C07.FR.05 and C07.FR.06, but it was not clear enough that only one of these fields is
needed.

The field certificate contains the entire contract certificate chain. It is only needed in case of central contract validation, where
Charging Station cannot locally validate the contract certificate, e.g. because it is lacking the root certificate. If certificate is
provided, it is no longer needed to provide iso15118CertificateHashData.

Text in bold is added to the description.

AuthorizeRequest
Field Name Field Type Card. Description
certificate string[0..5500] 0..1 Optional. The X.509 certificate chain presented by EV and
encoded in PEM format. Order of certificates in chain is
from leaf up to (but excluding) root certificate. Only
needed in case of central contract validation when
Charging Station cannot validate the contract certificate.
idToken IdTokenType 1..1 Required. This contains the identifier that needs to be
authorized.

OCPP 2.0.1 - © Open Charge Alliance 2024 40/145 Edition 2 - Errata 2024-04
Field Name Field Type Card. Description
iso15118CertificateHashDat OCSPRequestDataType 0..4 Optional. Contains the information needed to verify the
a EV Contract Certificate via OCSP. Not needed if
certificate is provided.

2.15.2. Page 381 - (2023-06) Updated description for idToken in

TransactionEventRequest [709]
The idToken in a TransactionEventRequest is only supposed to be sent after an id token has been authorized, either locally or
centrally. This happens when starting and stopping the authorization for a transaction. CSMS then returns the validity status of the
idToken in the TransactionRequestResponse. When a transaction is stopped via a RequestStopTransactionRequest or a
ResetRequest, no id token is involved and as a result no idToken should be provided in the TransactionEventRequest, because
CSMS does not need to check validity.

The description of idToken has been updated to make this clear.

Field Name Field Type Card. Description

Old idToken IdTokenType 0..1 Optional. This contains the identifier for which a transaction
text is (or will be) started or stopped. Is required when the EV
Driver becomes authorized for this transaction and when the
EV Driver ends authorization. The IdToken should only be
sent once in a TransactionEventRequest for every
authorization (for starting or for stopping) done for this
transaction.
New idToken IdTokenType 0..1 Optional. This contains the identifier for which a transaction
text is (or will be) started or stopped. Is required when the EV
Driver becomes authorized for this transaction and when the
EV Driver ends authorization. The IdToken should only be
sent once in a TransactionEventRequest for every
authorization (for starting or for stopping) done for this
transaction, so that CSMS can return the idTokenInfo in the
TransactionEventResponse.
idToken should not be present in the
TransactionEventRequest when a transaction is ended by a
RequestStopTransactionRequest or a ResetRequest.

2.16. Data Types

2.16.1. Page 386 - (2023-06) issuerKeyHash in CertificateHashDataType must be

type identifierString [691]
The field type of issuerKeyHash in CertificateHashDataType must be "identifierString[0..128]", instead of "string[0..128]". The
difference is, that identifierString is case-insensitive. This is, however, not checked by the JSON schema, and as a result this change
does not affect the JSON schema.

Changed field type for issuerKeyHash:

CertificateHashDataType

Field Name Field Type Card. Description

hashAlgorithm HashAlgorithmEnumType 1..1 Required. Used algorithms for the hashes provided.
issuerNameHash identifierString[0..128] 1..1 Required. The hash of the issuer’s distinguished name
(DN), that must be calculated over the DER encoding of
the issuer’s name field in the certificate being checked.
issuerKeyHash identifierString[0..128] 1..1 Required. The hash of the DER encoded public key: the
value (excluding tag and length) of the subject public key
field in the issuer’s certificate.
serialNumber identifierString[0..40] 1..1 Required. The string representation of the hexadecimal
value of the serial number without the prefix "0x" and
without leading zeroes.

OCPP 2.0.1 - © Open Charge Alliance 2024 41/145 Edition 2 - Errata 2024-04
2.16.2. Page 387 - (2024-02) 2.10 Description of chargingSchedule [743]
Multiple schedules are only allowed for TxProfile charging profile in the context of an ISO 15118 session. However, if one is not
implementing ISO 15118 support in OCPP (use cases K15-17) this fact may be missed. The description of chargingSchedule has
been updated to state that multiple schedules are only for TxProfile in an ISO 15118 charging session.

ChargingProfileType

Field Name Field Type Card. Description

…
Old chargingSchedule ChargingScheduleType 1..3 Required. Schedule that contains limits for the
available power or current over time. In order to
support ISO 15118 schedule negotiation, it supports at
most three schedules with associated tariff to choose
from.
New chargingSchedule ChargingScheduleType 1..3 Required. Schedule that contains limits for the
available power or current over time. In order to
support ISO 15118 schedule negotiation, it supports at
most three schedules with associated tariff to choose
from.
Having multiple chargingSchedules is only allowed for
charging profiles of purpose TxProfile in the
context of an ISO 15118 charging session.

2.16.3. Page 392 - (2024-02) EventDataType minor update of field trigger [740]
The description of field trigger refers to type of monitor that triggered this event, but it can also be from a hardwired notification.
Mention of monitor has been removed.

EventDataType

Field Name Field Type Card. Description

…
Old trigger EventTriggerEnumType 1..1 Required. Type of monitor that triggered this event,
e.g. exceeding a threshold value.
New trigger EventTriggerEnumType 1..1 Required. Type of trigger for this event, e.g. exceeding
a threshold value.
…

Page 415 - EventTriggerEnumType

The description of EventTriggerEnumType Alerting has been updated to make clear that this can also be used for a hardwired
notification.

EventTriggerEnumType

Value Description
Old Alerting Monitored variable has passed an Lower or Upper Threshold
New Alerting Monitored variable has passed a Lower or Upper Threshold.
Also used as trigger type for a HardWiredNotification .
…

2.16.4. Page 396 - (2023-06) NetworkConnectionProfileType [683]

The data type NetworkConnectionProfileType has two fields that do not serve a purpose.

• The field ocppVersion has no use, because the selection of the OCPP version that a charging station will use, is done during
the websocket handshake. It is not determined by the NetworkConnectionProfile.

OCPP 2.0.1 - © Open Charge Alliance 2024 42/145 Edition 2 - Errata 2024-04
 • The field ocppInterface is mandatory, but in most cases a CSMS will not even be aware of which interfaces a charging
station supports or should use to connect. It is a mandatory field, so CSMS must provide something, but that might not
match with the capability of the charging station. To remedy this, a charging station is allowed to use a different interface if
it cannot connect via the given ocppInterface.

The descriptions of these fields have been updated with text in bold to make this clear.

Changed descriptions in NetworkConnectionProfileType

Field Name Field Type Card. Description

ocppVersion OCPPVersionEnumType 1..1 Required. Defines the OCPP version used for this
communication function. This field is ignored, since the
OCPP version to use is determined during the
websocket handshake.
…
ocppInterface OCPPInterfaceEnumType 1..1 Required. Applicable Network Interface. Charging Station
is allowed to use a different network interface to
connect if the given one does not work.
…

2.16.5. Page 396 - (2023-12) NetworkConnectionProfileType [713]

The description of ocppCsmsUrl does not make clear that it is the URL without the charging station identity.

Changed description in NetworkConnectionProfileType

Field Name Field Type Card. Description

ocppCsmsUrl string[0..512] 1..1 Required. URL of the CSMS that this Charging Station
communicates with, without the Charging Station identity
part.
The SecurityCtrlr.Identity field is appended to
ocppCsmsUrl to provide the full websocket URL .

2.16.6. Page 404 - (2024-02) VariableCharacteristicsType.valuesList [725]

The description of field valuesList states that it is Optional, because it is only needed for Option/Member/SequenceList data types.
It does not make clear that it is mandatory for those types, otherwise a CSMS will never now what allowed choices are.

Changed description of valuesList as follows:

Field Name Field Type Card. Description

Old valuesList string[0..1000] 0..1 Optional. Allowed values when variable is
Option/Member/SequenceList.

* OptionList: The (Actual) Variable value must be a single

value from the reported (CSV) enumeration list.

* MemberList: The (Actual) Variable value may be an

(unordered) (sub-)set of the reported (CSV) valid values list.

* SequenceList: The (Actual) Variable value may be an

ordered (priority, etc) (sub-)set of the reported (CSV) valid
values.

This is a comma separated list.

The Configuration Variable ConfigurationValueSize can be

used to limit SetVariableData.attributeValue and
VariableCharacteristics.valueList. The max size of these
values will always remain equal.

OCPP 2.0.1 - © Open Charge Alliance 2024 43/145 Edition 2 - Errata 2024-04
 Field Name Field Type Card. Description
New valuesList string[0..1000] 0..1 Optional. Mandatory when dataType =
OptionList/MemberList/SequenceList. valuesList specifies
the allowed values for the type.

* OptionList: The (Actual) Variable value must be a single

value from the reported (CSV) enumeration list.

* MemberList: The (Actual) Variable value may be an

(unordered) (sub-)set of the reported (CSV) valid values list.

* SequenceList: The (Actual) Variable value may be an

ordered (priority, etc) (sub-)set of the reported (CSV) valid
values.

This is a comma separated list.

The Configuration Variable ConfigurationValueSize can be

used to limit SetVariableData.attributeValue and
VariableCharacteristics.valueList. The max size of these
values will always remain equal.

2.17. Enumerations

2.17.1. Page 416 - (2024-02) Description for FirmwareStatusEnumType

InstallRebooting
Value Description
Old InstallRebooting Intermediate state. Charging Station is about to reboot to activate new firmware. This status
MAY be omitted if a reboot is an integral part of the installation and cannot be reported
separately.
New InstallRebooting Intermediate State. If sent before installing the firmware, it indicates the Charging Station is
about to reboot to start installing new firmware. If sent after installing the new firmware, it
indicates the Charging Station has finished installing, but requires a reboot to activate the
new firmware, which will be done automatically when idle. This status MAY be omitted if a
reboot is an integral part of the installation and cannot be reported separately.

2.17.2. Page 419 - (2023-06) Description for idTokenEnumType MacAddress [664]

A description is missing for value MacAddress of IdTokenEnumType.

Value Description
MacAddress The MacAddress of the EVCC (Electric Vehicle Communication Controller) that is connected to the EVSE.
This is used as a token type when the MAC address is used for authorization ("Autocharge").

2.17.3. Page 427 - (2024-02) 3.68 RecurrencyKindEnumType [749]

The definition of Daily and Weekly recurrence is confusing, as it mentions restarting at beginning of the next day or next week, but
what is meant is, that it repeats every 24 hours or 7 days.

The description is updated as follows:

RecurrencyKindEnumType

Value Description
Old Daily The schedule restarts at the beginning of the next day.
New Daily The schedule restarts every 24 hours, at the same time as in the startSchedule .

OCPP 2.0.1 - © Open Charge Alliance 2024 44/145 Edition 2 - Errata 2024-04
 Value Description
Old Weekly The schedule restarts at the beginning of the next week (defined as Monday morning)
New Weekly The schedule restarts every 7 days, at the same time and day-of-the-week as in the startSchedule .

2.18. Referenced Components and Variables

2.18.1. Page 436 - (2023-12) Incorrectly referencing unit = "seconds" instead of "s"
[726]
There are a number of variables that have "unit = seconds", because it refers to an interval or timeout in seconds. The official unit
for seconds, however, is "s" as is stated in Appendix 2 "Standardized Units of Measure". Since this may be confusing, the field unit
must be changed in to "s" for all these variables.

This affects the following list of variables:

• DefaultMessageTimeout
• HeartbeatInterval
• OfflineThreshold
• MessageAttemptIntervalTransactionEvent
• WebSocketPingInterval
• TimeAdjustmentReportingThreshold
• CertSigningWaitMinimum
• AuthCacheLifeTime
• EVConnectionTimeout
• SampledDataTxEndedInterval
• SampledDataTxUpdatedInterval
• AlignedDataInterval
• AlignedDataTxEndedInterval

The field "unit" is only for information to CSMS. The description of the variables already makes clear that it is
NOTE
about seconds.

2.18.2. Page 436 - (2023-06) Websocket-related variables in Part 4 [690]

Add the following note below section heading "General":

NOTE WebSocket-related variables are described in "OCPP-2.0.1 Part 4 JSON over WebSockets".

Page 439 - 2.1.13 WebSocketPingInterval

This configuration variable at this location has "Required = No", but that is confusing, because it is required for a WebSocket
implementation. All WebSocket configuration variables are described in Part 4.

Replace table describing this variable with a reference to Part 4, as follows:

This configuration variable is described in "OCPP-2.0.1 Part 4 JSON over WebSockets".

2.18.3. Page 444 - (2023-06) SecurityCtrlr.BasicAuthPassword and Identity should

have dataType=string
The dataType of SecurityCtrlr.BasicAuthPassword is mistakenly shown as "passwordString". The content is similar to a
passwordString as defined in part 2, but the device model dataType is "string". The same applies to SecurityCtrlr.Identity which
shows dataType "identifierString".

OCPP 2.0.1 - © Open Charge Alliance 2024 45/145 Edition 2 - Errata 2024-04
Replace the descriptions of BasicAuthPassword and Identity by the updated text below. This change has also been made in
Part 2 Appendix chapter 3 "Standardized Components".

Updated dataType:
(change shown in bold italic)

BasicAuthPassword
The basic authentication password is used for HTTP Basic Authentication. The configuration value is write-only, so that it cannot be
accidentally stored in plaintext by the CSMS when it reads out all configuration values.

Required no
Component componentName SecurityCtrlr
Variable variableName BasicAuthPassword
variableAttributes mutability WriteOnly
variableCharacteristics dataType string
maxLimit 40 (Max length of the BasicAuthPassword)
Description The basic authentication password is used for HTTP Basic Authentication. The password SHALL be a randomly
chosen passwordString with a sufficiently high entropy, consisting of minimum 16 and maximum 40 characters
(alphanumeric characters and the special characters allowed by passwordString). The password SHALL be sent
as a UTF-8 encoded string (NOT encoded into octet string or base64). This configuration variable is write-only, so
that it cannot be accidentally stored in plaintext by the CSMS when it reads out all configuration variables.
This configuration variable is required unless only "security profile 3 - TLS with client side certificates" is
implemented.

Updated dataType:
(change shown in bold italic)

Identity

Required no
Component componentName SecurityCtrlr
Variable variableName Identity
variableAttributes mutability ReadOnly or ReadWrite
variableCharacteristics dataType string
maxLimit 48 (Charging Station Identity)
Description The Charging Station identity. Identity is an identifierString, however because this value is also used as the basic
authentication username, the colon character ':' SHALL not be used.
Maximum length was chosen to ensure compatibility with EVSE ID from [EMI3-BO] "Part 2: business objects".

2.18.4. Page 447 - (2024-02) 2.3.8 DisableRemoteAuthorization [751]

The description of AuthCtrlr.DisableRemoteAuthorization is hard to understand as it refers to the word DisablePostAuthorize twice
in the Note. It has now been rephrased to be clearer.

DisableRemoteAuthorization

Required no
Component componentName AuthCtrlr
Variable variableName DisableRemoteAuthorization
variableAttributes mutability ReadWrite
variableCharacteristics dataType boolean

Old When set to true this instructs the Charging Station to not issue any AuthorizationRequests, but only use
Description Authorization Cache and Local Authorization List to determine validity of idTokens.

Note: The difference with DisablePostAuthorize is that this variable disables all authorization with CSMS,
whereas DisablePostAuthorize only disables re-authorization of tokens that are as not-Accepted in the
Authorization Cache or Local Authorization List.

OCPP 2.0.1 - © Open Charge Alliance 2024 46/145 Edition 2 - Errata 2024-04
New When set to true this instructs the Charging Station to not issue any AuthorizationRequests, but only use
Description Authorization Cache and Local Authorization List to determine validity of idTokens.

Note: The difference between AuthCtrlr.DisableRemoteAuthorization and

AuthCacheCtrlr.DisablePostAuthorization is that the latter only disables re-authorization of tokens that are as not-
Accepted in the Authorization Cache or Local Authorization List, whereas AuthCtrlr.DisableRemoteAuthorization
disables all authorization with CSMS.

2.18.5. Page 452 - (2023-06) Incomplete description TxStopPoint Authorized and

PowerPathClosed [704]
A transaction shall not end while energy transfer is still ongoing, otherwise it is not possible to report a correct final meter value for
the transaction. TxStopPoints Authorized and PowerPathClosed will trigger the transaction to be ended after a StopAuthorized or
Deauthorized event, but the Charging Station must wait until the energy transfer has been ended, before transmitting the
TransactionEventRequest with eventType = Ended, so that this message can contain the final meter values.

The description of these TxStopPoints has been enhanced to make this clear.

2.6.6.2 TxStopPoint values

Value Description
Authorized Driver or EV is no longer authorized, this can also be some form of
anonymous authorization like a start button. The end of
authorization will cause the Charging Station to stop the energy
transfer, after which the TransactionEventRequest with eventType
= Ended will be transmitted.
PowerPathClosed All preconditions for charging are no longer met. This event is the
logical OR of EVConnected and Authorized and should be used
if a transaction is supposed to end when EV is disconnected and/or
deauthorized. This will cause the Charging Station to stop the
energy transfer, after which the TransactionEventRequest with
eventType = Ended will be transmitted. It is exactly the same as
having the values EVConnected, Authorized in TxStopPoint.
Despite its name, this event is not related to the state of the power
relay.

2.18.6. Page 454 - (2024-04) SampledDataTxEndedMeasurands/Interval: updated

description[746]

SampledDataTxEndedMeasurands
The highlighted text is added to the description to clarify that the end value must also be included as a sampled value.

Required yes
Component componentName SampledDataCtrlr
Variable variableName TxEndedMeasurands
variableAttributes mutability ReadWrite
variableCharacteristics dataType MemberList
maxLimit The maximum length of the CSV formatted string, to
be defined by the implementer.
Description Sampled measurands to be included in the meterValues element of TransactionEventRequest (eventType =
Ended), every SampledDataTxEndedInterval seconds from the start of the transaction until and including the
last measurands at the end of the transaction .
The Charging Station reports the list of supported Measurands in VariableCharacteristicsType.valuesList of this
variable. This way the CSMS knows which Measurands it can put in the TxEndedSampledData.

When left empty, no sampled measurands SHALL be put into the TransactionEventRequest (eventType = Ended).

SampledDataTxEndedInterval

OCPP 2.0.1 - © Open Charge Alliance 2024 47/145 Edition 2 - Errata 2024-04
Required yes
Component componentName SampledDataCtrlr
Variable variableName TxEndedInterval
variableAttributes mutability ReadWrite
variableCharacteristics unit seconds
dataType integer
Description Interval between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest
(eventType = Ended) message. For transaction data (evseId>0), samples are acquired and transmitted only in the
TransactionEventRequest (eventType = Ended) message.

A value of "0" (numeric zero), by convention, is to be interpreted to mean that only the values taken at the start and
end of a transaction SHALL be transmitted (no intermediate values). A TxEndedInterval = 0 is recommended, since
other values may result in a lot of data to be transmitted in the TransactionEventRequest ( eventType = Ended )
message.

2.18.7. Page 454 - (2024-04) AlignedDataMeasurands/Interval: updated

description [746]
The highlighted text is added to clarify that clock-aligned measurands can also be sent in a TransactionEventRequest when related
to a transaction.

2.18.8. AlignedDataMeasurands
Required yes
Component componentName AlignedDataCtrlr
Variable variableName Measurands
variableAttributes mutability ReadWrite
variableCharacteristics dataType MemberList
maxLimit The maximum length of the CSV formatted string, to
be defined by the implementer.
Description Clock-aligned measurand(s) to be included in MeterValuesRequest or TransactionEventRequest , every
AlignedDataInterval seconds. For all the allowed values see: Measurand.
The Charging Station reports the list of supported Measurands in VariableCharacteristicsType.valuesList of this
variable. This way the CSMS knows which Measurands it can put in the AlignedDataMeasurands.

The sentences about accumulating or averaging measurands for clock-aligned readings has been removed (shown as strike-
through), because it is not covered by any requirements and does not make sense for register measurands.

AlignedDataInterval
Required yes
Component componentName AlignedDataCtrlr
Variable variableName Interval
variableAttributes mutability ReadWrite
variableCharacteristics unit seconds
dataType integer
Description Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the MeterValuesRequest or
TransactionEventRequest message. This is the size (in seconds) of the set of evenly spaced aggregation intervals
per day, starting at 00:00:00 (midnight). For example, a value of 900 (15 minutes) indicates that every day should
be broken into 96 15-minute intervals.
When clock aligned data is being transmitted, the interval in question is identified by the start time and (optional)
duration interval value, represented according to the ISO8601 standard. All "per-period" data (e.g. energy readings)
should be accumulated (for "flow" type measurands such as energy), or averaged (for other values) across the
entire interval (or partial interval, at the beginning or end of a transaction), and transmitted (if so enabled) at the
end of each interval, bearing the interval start time timestamp.
A value of "0" (numeric zero), by convention, is to be interpreted to mean that no clock-aligned data should be
transmitted.

OCPP 2.0.1 - © Open Charge Alliance 2024 48/145 Edition 2 - Errata 2024-04
AlignedDataTxEndedInterval
Required yes
Component componentName AlignedDataCtrlr
Variable variableName TxEndedInterval
variableAttributes mutability ReadWrite
variableCharacteristics unit seconds
dataType integer
Description Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the TransactionEventRequest
(eventType = Ended) message. This is the size (in seconds) of the set of evenly spaced aggregation intervals per
day, starting at 00:00:00 (midnight). For example, a value of 900 (15 minutes) indicates that every day should be
broken into 96 15-minute intervals.
When clock aligned data is being collected, the interval in question is identified by the start time and (optional)
duration interval value, represented according to the ISO8601 standard. All "per-period" data (e.g. energy readings)
should be accumulated (for "flow" type measurands such as energy), or averaged (for other values) across the
entire interval (or partial interval, at the beginning or end of a transaction), and All intervals are transmitted (if so
enabled) at the end of the transaction in 1 TransactionEventRequest (eventType = Ended) message.
This is not a recommended practice, since the size of the message can become very large.

2.18.9. Page 469 - (2024-02) ProtocolSupportedByEV is read-only [734]

The variable ConnectedEV.ProtocolSupportedByEV and ConnectedEV.ProtocolAgreed are shown as ReadWrite, but these must be
ReadOnly. This value cannot be set by CSMS.

ProtocolSupportedByEV

Required no
Component componentName ConnectedEV
evse *
Variable variableName ProtocolSupportedByEV
variableInstance <Priority>
variableAttributes mutability ReadOnly
variableCharacteristics dataType string
Description A string with the following comma-separated items:
“<uri>,<major>,<minor>”.
This is information from the supportedAppProtocolReq message from ISO 15118
Each priority is given its own variable instance. Priority is a number from 1 to 20 as a string. E.g. "1" or "2".
Example:
- ConnectedEV.ProtocolSupportedByEV["1"] = "urn:iso:15118:2:2013:MsgDef,2,0"
- ConnectedEV.ProtocolSupportedByEV["2"] = "urn:iso:15118:2:2010:MsgDef,1,0"

ProtocolAgreed

Required no
Component componentName ConnectedEV
evse *
Variable variableName ProtocolAgreed
variableAttributes mutability ReadOnly
variableCharacteristics dataType string
Description A string with the following comma-separated items:
“<uri>,<major>,<minor>”.
This is the protocol uri and version information that was agreed upon between EV and EVSE in the
supportedAppProtocolReq handshake from ISO 15118.
Example: "urn:iso:15118:2:2013:MsgDef,2,0"

OCPP 2.0.1 - © Open Charge Alliance 2024 49/145 Edition 2 - Errata 2024-04
2.19. Appendix 1

2.19.1. Page 2 - (2023-06) InvalidFirmwareSignature/SigningCertificate are critical

security events [682]
The column "Critical" must be set to "yes" for a security event InvalidFirmwareSignature and InvalidFirmwareSigningCertificate,
because of the SHALL-requirements L01.FR.02 and L01.FR.03.

Security Event Description Critical

InvalidFirmwareSignature The firmware signature is not valid Yes
InvalidFirmwareSigningCertificate The certificate used to verify the firmware signature is not valid Yes

2.20. Appendix 3

2.20.1. Page 9 - (2023-06) OCPPCommCtrlr.ActiveNetworkProfile must be of type

integer [697]
ActiveNetworkProfile was mistakenly shown as having type string. This must be integer.

OCPPCommCtrlr

Description
Logical Component responsible for configuration relating to information exchange between Charging Station and CSMS.
Variables Type Description
ActiveNetworkProfile integer […]

2.20.2. Page 10 - (2023-06) SecurityCtrlr.BasicAuthPassword and Identity should

have dataType=string [698]
BasicAuthPassword was shown as type "passwordString" and for Identity as type "identifierString". The type for the device model
variable in both cases must be "string".

SecurityCtrlr

Description
Logical Component responsible for configuration relating to security of communications between Charging Station and CSMS.
Variables Type Description
BasicAuthPassword string […]
Identity string […]

2.21. Appendix 5

2.21.1. Page 36 - (2023-12) ReasonCodes MissingDeviceModelInfo and

InvalidMessageSequence exceed 20 chars [720]
ReasonCodes MissingDeviceModelInfo and InvalidMessageSequence exceed 20 characters of reasonCode field. These needed to
be shortened.

Old reason code name New reason code name

MissingDeviceModelInfo MissingDevModelInfo
InvalidMessageSequence InvalidMessageSeq

OCPP 2.0.1 - © Open Charge Alliance 2024 50/145 Edition 2 - Errata 2024-04
Page 276 - Requirement K15.FR.17
ReasonCode InvalidMessageSequence is referenced in K15.FR.17 and needs to be updated.

Changed requirement

ID Precondition Requirements Note

Old K15.FR.1 When Charging The Charging Station SHOULD respond CSMS sent profile too early. It does not
7 Station receives a with SetChargingProfileResponse with harm if CS accepts the charging profile
SetChargingProfileR status = Rejected and a statusInfo with instead of rejecting it, as long as it sends a
equest immediately reasonCode= charging profile again when it receives the
after the transaction InvalidMessageSequence. NotifyEVChargingNeedsRequest.
has started and
before it has sent
the
NotifyEVChargingNe
edsRequest to CSMS
New K15.FR.1 When Charging The Charging Station SHOULD respond CSMS sent profile too early. It does not
7 Station receives a with SetChargingProfileResponse with harm if CS accepts the charging profile
SetChargingProfileR status = Rejected and a statusInfo with instead of rejecting it, as long as it sends a
equest immediately reasonCode= InvalidMessageSeq . charging profile again when it receives the
after the transaction NotifyEVChargingNeedsRequest.
has started and
before it has sent
the
NotifyEVChargingNe
edsRequest to CSMS

OCPP 2.0.1 - © Open Charge Alliance 2024 51/145 Edition 2 - Errata 2024-04
3. Part 3
Currently no new errata for OCPP 2.0.1 part 3.

OCPP 2.0.1 - © Open Charge Alliance 2024 52/145 Edition 2 - Errata 2024-04
4. Part 4
4.1. Page 8 - (2023-12) - section 3.1.2. No OCPP version in endpoint
URL [732]
If websocket protocol negotiotion is to be used, the OCPP version should not be part of the endpoint URL. Therefore, the following
paragraph in section 3.1.2 needs to be changed.

Changed text

3.1.2 OCPP version

The OCPP version(s) MUST be specified in the Sec-Websocket-Protocol field. This SHOULD be one or more of the following
values:

Table 3. OCPP Versions

OCPP version WebSocket subprotocol name
1.2 ocpp1.2
1.5 ocpp1.5
1.6 ocpp1.6
2.0 ocpp2.0
2.0.1 ocpp2.0.1

The ones for OCPP 1.2, 1.5, 1.6, 2.0 and 2.0.1 are official WebSocket subprotocol name values. They are registered as such
with IANA.

Note that OCPP 1.2 and 1.5 are in the list. Since the JSON over WebSocket solution is independent of the actual message
content the solution can be used for older OCPP versions as well. Please keep in mind that in these cases the implementation
should preferably also maintain support for the SOAP based solution to be interoperable.

It is considered good practice to include the OCPP version as part of the OCPP-J endpoint URL string. If you run a web service
that can handle multiple protocol versions on the same OCPP-J endpoint URL this is not necessary of course. The OCPP
version should not be part of the OCPP-J endpoint URL string if you want to select the OCPP version to use via the websocket
protocol negotiation mechanism, as explained in Server Response .

4.2. Page 10 - (2023-12) - Section 4.1.4. The message ID must be

unique [702]
The text in section 4.1.4 uses the wording "on the same WebSocket connection". This can, however, be interpreted in multiple ways.
It was intended to mean that that the messageId must be different from all messageIds previously used by the same sender for any
other CALL message on any WebSocket connection using the same unique Charging Station identifier. The current wording seems
to indicate that it may use the same messageId after every reconnect, however this may cause major issues. Especially when
looking at the OCPP message queuing mechanisms.

Changed text:

4.1.4 The message ID

The message ID serves to identify a request. A message ID for any CALL message MUST be different from all message IDs
previously used by the same sender for any other CALL message on any WebSocket connection using the same unique
Charging Station identifier. A message ID for a CALLRESULT or CALLERROR message MUST be equal to that of the CALL
message that the CALLRESULT or CALLERROR message is a response to.

Table 4. Unique Message ID

Name Datatype Restrictions
messageId string[36] Unique message ID, maximum length of 36 characters, to allow for UUIDs/GUIDs

OCPP 2.0.1 - © Open Charge Alliance 2024 53/145 Edition 2 - Errata 2024-04
4.3. Page 10 - (2024-02) 4.1.4 The message ID [738]
The text in 4.1.4 did not make explicit that even for retried messages a new message ID must be used. The highlighted sentence
has been added.

4.1.4. The message ID

The message ID serves to identify a request. A message ID for any CALL message MUST be different from all message IDs
previously used by the same sender for any other CALL messages on the any WebSocket connection using the same unique
Charging Station identifier. This also applies to retries of messages.
A message ID for a CALLRESULT or CALLERROR message MUST be equal to that of the CALL message that the
CALLRESULT or CALLERROR message is a response to.

OCPP 2.0.1 - © Open Charge Alliance 2024 54/145 Edition 2 - Errata 2024-04
5. Part 5
5.1. Features

5.1.1. Page 7 - (2024-02) - Optional feature list for charging station - C-43 - incorrect variable reference at description
See also the next erratum.

Id Feature Charging Station

Old text C-43 Install Firmware with ongoing transaction(s) (AllowNewSessionsPendingFirmwareUpdate) Optional
New text C-43 Install Firmware with ongoing transaction(s) Optional

5.1.2. Page 7 - (2024-04) - Optional feature list for charging station - C-43 - description extended
Id Feature Charging Station
Old text C-43 Install Firmware with ongoing transaction(s) Optional
New text C-43 Install and activate Firmware with ongoing transaction(s) Optional

5.2. List of test cases

5.2.1. Page 11 - (2023-12) - TC_B_08_CS should not be tested

This test case tests requirement B06.FR.05, which is not a Charging Station requirement. The limit must be respected (not tested) by the CSMS / OCTT.

OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Removed TC_B_08 limit to maximum number of values C If the Charging Station supports ORS-5 BytesPerMessageGetVariables
BytesPerMessageGetVariables

5.2.2. Page 13 - (2023-12) - TC_B_50_CS - Testcase not only applicable for AdditionalRootCertificateCheck = true
This test case was conditional for feature AdditionalRootCertificateCheck, however this can always be performed (no relation with AdditionalRootCertificateCheck) Due to the importance of the
functionality, the condition has been removed and the testcase has become mandatory.

OCPP 2.0.1 - © Open Charge Alliance 2024 55/145 Edition 2 - Errata 2024-04
 OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_B_50 Success - New CSMS Root - New CSMS C For CS: at least two configuration slots for AS-2 Additional Root Certificate check
networkConnectionProfiles must be
supported
New text TC_B_50 Success - New CSMS Root - New CSMS M For CS: at least two configuration slots for
networkConnectionProfiles must be
supported

5.2.3. Page 13-23 - (2023-12) - A number of test cases cannot be run for a Charging Station that only supports
NoAuthorization as a local authorization option
We found that a number of test cases cannot be run for a Charging Station that only supports NoAuthorization as a local authorization option (and it is not possible with the supported remote
authorization options). Test cases for statuses like Invalid, Authorization Cache, Local Auth. List, GroupId etc. will be dropped for this type of Charging Station implementation.

OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_C_02 Authorization Invalid/Unknown C M Charging Station: (C-30 or C-31 or C-32 Local Authorization - using RFID
- The Charging Station supports at least one or C-35 ) and NOT AQ- ISO14443 / RFID ISO15693 /
of the following local start authorization 2 KeyCode / NoAuthorization and
options C-30, C-31, C-32, C35 Does the Charging Station have a
- The Charging Station does NOT have a cable lock, which prevents the EV
cable lock that prevents the EV driver to driver to connect the EV and
connect the EV and EVSE before EVSE before authorization?
authorization.
New text TC_C_02 Authorization Invalid/Unknown C M Charging Station: (C-30 or C-31 or C-32) Local Authorization - using RFID
- The Charging Station supports at least one and NOT AQ-2 ISO14443 / RFID ISO15693 /
of the following local start authorization KeyCode and
options C-30, C-31, C-32 Does the Charging Station have a
- The Charging Station does NOT have a cable lock, which prevents the EV
cable lock that prevents the EV driver to driver to connect the EV and
connect the EV and EVSE before EVSE before authorization?
authorization.

OCPP 2.0.1 - © Open Charge Alliance 2024 56/145 Edition 2 - Errata 2024-04
 OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_C_05 Authorization invalid - Cable lock C For CS: (C-30 or C-31 or C-32 Local Authorization - using RFID
- The Charging Station has a cable lock, or C-35 ) and AQ-2 ISO14443 / RFID ISO15693 /
which prevents the EV driver to connect the KeyCode / NoAuthorization
EV and EVSE before authorization.
- The Charging Station supports at least one
of the following local start authorization
options C-30, C-31, C-32, C35
- The Charging Station does NOT have the
following configuration: TxStartPoint
ReadOnly AND value Authorized is NOT set.
New text TC_C_05 Authorization invalid - Cable lock C For CS: (C-30 or C-31 or C-32) Local Authorization - using RFID
- The Charging Station has a cable lock, and AQ-2 ISO14443 / RFID ISO15693 /
which prevents the EV driver to connect the KeyCode
EV and EVSE before authorization.
- The Charging Station supports at least one
of the following local start authorization
options C-30, C-31, C-32.
- The Charging Station does NOT have the
following configuration: TxStartPoint
ReadOnly AND value Authorized is NOT set.
Old text TC_E_52 DisableRemoteAuthorization C If the Charging Station supports the option C-58
for disabling remote authorization
New text TC_E_52 DisableRemoteAuthorization C If the Charging Station supports the option C-58 and (C-30 or C- Local Authorization - using RFID
for disabling remote authorization and 31 or C-32) and (C-49 ISO14443 / RFID ISO15693 /
The Charging Station supports at least one or Local KeyCode & Authorization Cache
of the following local start authorization Authorization List & Local Authorization List.
Management)
options C-30, C-31, C-32 and
Either Authorization Cache or Local
Authorization List is supported.
Old text TC_E_16 Deauthorized - Invalid idToken C M TxStopPoint can either be ReadOnly with a (C-10.2 or C-10.3) Supported Transaction Stop
subset of the values or have a valueList of and (C-30 - C-35 or Points & Local Authorization
supported values, that contains a subset. ISO 15118 support) options for local start &
This testcase is applicable if the value and C-01 Authorization - eMAID
Authorized or PowerPathClosed is a
supported value.
Charging Station: If one or more of the local
start authorization options is implemented.
AND either a cache, local authorization list
or UnknownIdtag (C15) is implemented.

OCPP 2.0.1 - © Open Charge Alliance 2024 57/145 Edition 2 - Errata 2024-04
 OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
New text TC_E_16 Deauthorized - Invalid idToken C M TxStopPoint can either be ReadOnly with a (C-10.2 or C-10.3) Supported Transaction Stop
subset of the values or have a valueList of and (C-30 - C-32 or Points & Local Authorization
supported values, that contains a subset. ISO 15118 support) options for local start &
This testcase is applicable if the value and C-01 Authorization - eMAID
Authorized or PowerPathClosed is a
supported value.
Charging Station: If one or more of the local
start authorization options is implemented.
AND either a cache, local authorization list
or UnknownIdtag (C15) is implemented.
Old text TC_E_43 Transaction during offline period C Charging Station: If one or more of the local C-01 and (C-30 - C-35 Offline transaction support &
start authorization options is implemented. or ISO 15118 Local Authorization options for
support) local start
New text TC_E_43 Transaction during offline period C Charging Station: If offline authorization is (C-01 and (C-30 - C- Offline transaction support &
supported and one or more of the local start 34 or ISO 15118 Local Authorization options for
authorization options is implemented. support)) or C-35 local start or NoAuthorization
Or the Charging Station supports support
NoAuthorization.
Old text TC_E_44 Stop transaction during offline period C Charging Station: If one or more of the local C-01 and (C-30 - C-35 Offline transaction support &
start authorization options is implemented. or ISO 15118 Local Authorization options for
support) local start & Authorization -
eMAID
New text TC_E_44 Stop transaction during offline period C Charging Station: If one or more of the local C-30 - C-35 or ISO Local Authorization options for
start authorization options is implemented. 15118 support local start & Authorization -
eMAID

5.2.4. Page 19 - (2023-12) - TC_E_20_CS Improved condition / remark and aligned the conditions at feature no.
TC_E_20_CS is the equivalent of TC_E_54_CS, that covers the scenario for a Charging Station that supports charging a IEC 61851-1 EV. The condition / remark was still missing this information.
The condition listed at the feature no. column is one of the most complicated ones that exists in part 5. We also noticed that it did not correctly cover the described remarks for all permutations,
so it has been improved.

OCPP 2.0.1 - © Open Charge Alliance 2024 58/145 Edition 2 - Errata 2024-04
 OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_E_20 EVDisconnected - EV side (able to charge C M TxStopPoint can either be ReadOnly with a C-10.1 and (C-52 or Supported Transaction Stop
IEC 61851-1 EV) subset of the values or have a valueList of NOT (C-10.2 or C-10.3 points
supported values, that contains a subset. or C-10.4)) AND NOT
This testcase is applicable if the value C-06.1) AND (AQ-9
EVConnected is a supported value. And it OR Product Subtype
should be possible to not set EnergyTransfer "Mode 1/2-only
and PowerPathClosed AND Charging Station")
The Charging Station does NOT have
following configuration combination;
StopTxOnEVSideDisconnect mutability
ReadOnly with value true AND TxStopPoint
mutability is ReadOnly and contains
Authorized
New text TC_E_20 EVDisconnected - EV side (able to charge C M TxStopPoint can either be ReadOnly with a (C-10.1 AND (NOT Supported Transaction Stop
IEC 61851-1 EV) subset of the values or have a valueList of (NOT C-52 AND (C- points
supported values, that contains a subset. 10.3 or C-10.4))) AND
This testcase is applicable if the value NOT (NOT C.06.1
EVConnected is a supported value. And it AND NOT C-52 AND
should be possible to not set EnergyTransfer C-10.2)) AND (AQ-9
and PowerPathClosed AND OR Product Subtype
The Charging Station does NOT have "Mode 1/2-only
following configuration combination; Charging Station")
StopTxOnEVSideDisconnect mutability
ReadOnly with value true AND TxStopPoint
mutability is ReadOnly and contains
Authorized AND
the Charging Station supports charging an
EV using IEC 61851-1 (Mode 3) or is a Mode
1/2-only Charging Station.

5.2.5. Page 20 - (2023-12) - TC_E_54_CS Improved condition / remark and aligned the conditions at feature no.
TC_E_54_CS was created to accommodate testing TC_E_20_CS with a Charging Station that supports high level communication. We noticed that the OCPP communication is different in that
case. The condition / remark was still missing this information. The condition listed at the feature no. column is one of the most complicated ones that exists in part 5. We also noticed that it did
not correctly cover the described remarks for all permutations, so it has been improved.

OCPP 2.0.1 - © Open Charge Alliance 2024 59/145 Edition 2 - Errata 2024-04
 OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_E_54 EVDisconnected - EV side (not able to C TxStopPoint can either be ReadOnly with a C-10.1 and (C-52 or Supported Transaction Stop
charge IEC 61851-1 EV) subset of the values or have a valueList of NOT (C-10.2 or C-10.3 points
supported values, that contains a subset. or C-10.4)) AND (HFS-
This testcase is applicable if the value 4 OR ISO15118
EVConnected is a supported value. And it support) AND NOT
should be possible to not set EnergyTransfer Product Subtype
and PowerPathClosed AND "Mode 1/2-only
The Charging Station does NOT have Charging Station"
following configuration combination;
StopTxOnEVSideDisconnect mutability
ReadOnly with value true AND TxStopPoint
mutability is ReadOnly and contains
Authorized
New text TC_E_54 EVDisconnected - EV side ( DC and/or ISO- C TxStopPoint can either be ReadOnly with a C-10.1 AND (NOT Supported Transaction Stop
15118 Support ) subset of the values or have a valueList of (NOT C-52 AND (C- points
supported values, that contains a subset. 10.2 or C-10.3 or C-
This testcase is applicable if the value 10.4))) AND (HFS-4
EVConnected is a supported value. And it OR ISO15118
should be possible to not set EnergyTransfer support) AND NOT
and PowerPathClosed AND Product Subtype
The Charging Station does NOT have "Mode 1/2-only
following configuration combination; Charging Station"
StopTxOnEVSideDisconnect mutability
ReadOnly with value true AND TxStopPoint
mutability is ReadOnly and contains
Authorized AND
the Charging Station has DC or ISO-15118
support AND
is NOT a Mode 1/2-only Charging Station.

5.2.6. Page 21 - (2023-12) - TC_E_39_CS - Testcase not only applicable for TxStopPoint Authorized
This test case was conditional for TxStopPoint Authorized, however this testcase can always be performed. Due to the importance of this functionality, the condition has been removed and the
testcase has become mandatory.

OCPP 2.0.1 - © Open Charge Alliance 2024 60/145 Edition 2 - Errata 2024-04
 OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_E_39 Deauthorized - timeout C M TxStopPoint can either be ReadOnly with a C-10.2 Supported Transaction Stop
subset of the values or have a valueList of points
supported values, that contains a subset.
This testcase is applicable if the value
Authorized is a supported value.
New text TC_E_39 Deauthorized - timeout M M

5.2.7. Page 22 - (2024-02) - TC_E_31_CS - Changed mandatory testcase to conditional

During testing it was noticed that there is a very specific condition in which this testcase cannot be executed.

OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_E_31 Transaction with id ended - with message in M C C-16 Check TransactionStatus
queue
New text TC_E_31 Transaction with id ended - with message in C C Charging Station: CSMS: C-16 CSMS:
queue The following combination of conditions are Check TransactionStatus
Charging Station:
NOT true: NOT (
- No local authorization methods are NOT (C-30 - C-35)
supported AND AND
- TxStopPoint mutability is false and only (NOT C-10.1 AND
contains Authorized AND NOT C-10.3 AND NOT
- TxCtrlr.StopTxOnEVSideDisconnect C-10.4 AND NOT C-
mutability is false and value is false 10.5) AND
NOT C-06.2
)

5.2.8. Page 24 - (2023-12) - TC_F_04_CS should only be applicable when TxStartPoint Authorized or
ParkingBayOccupancy are supported
Note: This erratum has been superseded by erratum: [Page 24 - (2024-02) - TC_F_04_CS - condition needs to be kept inline with TC_E_05_CS]

For this cable plugin timeout testcase we can only check the transmitted OCPP TransactionEventRequest messages, to validate the behavior. So the testcase is only testable if the Charging
Station supports starting the transaction before the cable is plugged in. If the Charging Station does not support TxStartPoint Authorized or ParkingBayOccupancy, it must still support the cable
plugin timeout mechanism itself.

OCPP 2.0.1 - © Open Charge Alliance 2024 61/145 Edition 2 - Errata 2024-04
 OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_F_04 Remote start first - Cable plugin timeout M M
New text TC_F_04 Remote start first - Cable plugin timeout C M TxStartPoint can either be ReadOnly with a C-09.2 or C-09.6 Supported Transaction Start
subset of the values or have a valueList of points
supported values, that contains a subset.
This testcase is applicable if the value
Authorized or ParkingBayOccupancy is a
supported value.

5.2.9. Page 24 - (2024-02) - TC_F_04_CS - condition needs to be kept inline with TC_E_05_CS
The testcase has been adjusted to support testing with all possible TxStartPoint values.

OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_F_04 Remote start first - Cable plugin timeout C M TxStartPoint can either be ReadOnly with a C-09.2 or C-09.6 Supported Transaction Start
subset of the values or have a valueList of points
supported values, that contains a subset.
This testcase is applicable if the value
Authorized or ParkingBayOccupancy is a
supported value.
New text TC_F_04 Remote start first - Cable plugin timeout M M

5.2.10. Page 28 - (2024-04) - TC_L_14_CS and TC_L_15_CS - name changed

OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_L_14 Unable to install firmware with ongoing C AllowNewSessionsPendingFirmwareUpdate C-20 and NOT C-43 AllowNewSessionsPendingFirm
transaction - is implemented. and AQ-7 and HFS-8 > wareUpdate
AllowNewSessionsPendingFirmwareUpdate The Charging Station is unable to install 1
is true firmware while there is an ongoing
transaction

OCPP 2.0.1 - © Open Charge Alliance 2024 62/145 Edition 2 - Errata 2024-04
 OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Old text TC_L_15 Unable to install firmware with ongoing C AllowNewSessionsPendingFirmwareUpdate NOT C-43 and AQ-7
transaction - is implemented.
AllowNewSessionsPendingFirmwareUpdate The Charging Station is unable to install
is false firmware while there is an ongoing
transaction
New text TC_L_14 Unable to install and activate firmware with C AllowNewSessionsPendingFirmwareUpdate C-20 and NOT C-43 AllowNewSessionsPendingFirm
ongoing transaction - is implemented. and AQ-7 and HFS-8 > wareUpdate
AllowNewSessionsPendingFirmwareUpdate The Charging Station is unable to install 1
is true firmware while there is an ongoing
transaction
New text TC_L_15 Unable to install and activate firmware with C AllowNewSessionsPendingFirmwareUpdate NOT C-43 and AQ-7
ongoing transaction - is implemented.
AllowNewSessionsPendingFirmwareUpdate The Charging Station is unable to install
is false firmware while there is an ongoing
transaction

5.2.11. Page 29 - (2024-02) - TC_M_23_CS - testcase is mandatory for Advanced Security, not for Core
This testcase tests if the client certificate cannot be removed using the DeleteCertificateRequest. Client certificates are only used when supporting Advanced Security with security profile 3.

Removed from Core profile

OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Removed TC_M_23 Unable to delete the Charging Station M
Certificate

Added to Advanced Security profile

OCTT Id OCPP Compliance Testing Tool scenario Conf. Test Conf. test Condition / remark Feature no. Feature
for for CSMS
Charging
Station
Added TC_M_23 Unable to delete the Charging Station M
Certificate

OCPP 2.0.1 - © Open Charge Alliance 2024 63/145 Edition 2 - Errata 2024-04
5.2.12. Page 32 - (2024-04) - Added testcase list for the other certification profiles
At edition 3 of the specification all testcases for the other certification profiles are included.
The included certification profiles;

• Local Authorization List Management

• Smart Charging
• Advanced Device Management
• Reservation
• Advanced User Interface
• ISO 15118 Support

OCPP 2.0.1 - © Open Charge Alliance 2024 64/145 Edition 2 - Errata 2024-04
6. Part 6
6.1. Test Cases Charging Station

6.1.1. Page 3 - (2023-12) - General tool rules/validations - Added information for

idToken type NoAuthorization
Added When idToken type NoAuthorization is configured to be used, the OCTT will act/validate differently. No
AuthorizeRequest is expected anymore and the value of the idToken at the TransactionEventRequest should be
an empty string "". Additionally many testcases like Authorization cache, local authorization list, groupIdToken,
etc. Will not work for this idToken type.

6.1.2. Page 24 - (2024-04) - TC_A_22_CS - Fixed wrong description of test

Description and purpose of this test case contained the wrong text.

Test case name Upgrade Charging Station Security Profile - Downgrade security profile - Rejected
Test case Id TC_A_22_CS
Use case Id(s) A05, B09
Requirement(s) B09.FR.04
System under test Charging Station
Old Description The CSMS is able to change the connectionData at the Charging Station. By doing this it is able to
text upgrade the connection to a higher security profile.
New Description The CSMS is able to change the connectionData at the Charging Station. It tries to downgrade the
text connection to a lower security profile.
Old Purpose To verify if the Charging Station is able to reject upgrading to a higher security profile when it does
text not have a valid ChargingStationCertificate installed.
New Purpose To verify if the Charging Station is able to reject downgrading to a lower security profile than the
text currently active security profile .

6.1.3. Page 30 - (2023-12) - TC_B_30_CS - Removed prerequisite and added note

The testcase has been made more robust to also work for Charging Station that disconnect during this testcase.

Old text Prerequisite(s) The Charging Station is configured to keep the connection open while it is waiting to
resend the BootNotificationRequest.
New text Prerequisite(s)

Added note to main step

Old text 3. The OCTT sends a GetBaseReportRequest

with reportBase FullInventory
New text 3. The OCTT sends a GetBaseReportRequest
with reportBase FullInventory
Note(s) : The OCTT will only send this request if the Charging Station does not disconnect

6.1.4. Page 36 - (2023-12) - TC_B_08_CS - Removed testcase

This test case tests requirement B06.FR.05, which is not a Charging Station requirement. The limit must be respected, not tested by
the OCTT. There fore it will be removed from part 6.

Removed testcase

OCPP 2.0.1 - © Open Charge Alliance 2024 65/145 Edition 2 - Errata 2024-04
6.1.5. Page 42 - (2023-12) - TC_B_11_CS - Changed hardcoded values for integer
and decimal to configurable values
The defined hardcoded values were not usable for all Charging Stations.

Changed main step

Old text Notes:

Steps 1 to 8 are repeated 5 times for value = 1, 1.1, true, currentTime, "abc"
New text Notes:
Steps 1 to 8 are repeated 5 times for value = <configured offlineThreshold>, <configured offlineThreshold + 0.1> ,
true, currentTime, "abc"

Additionally, step 3 and 4 regarding setting values to "SmartChargingCtrlr.LimitChangeSignificance" is only tested if the Charging
Station supports it.

Added note to main steps

Added Notes:
Steps 3 and 4 will only be tested if this component/variable combination is supported

6.1.6. Page 50 - (2023-12) - TC_B_21_CS - Removed requirement reference

This requirement was removed from part 2 specification.

Old text Requirement(s) B12.FR.01, B12.FR.03 , E07.FR.03

New text Requirement(s) B12.FR.01, B12.FR.03

6.1.7. Page 56 - (2023-12) - TC_B_41_CS - Typo step reference

Typo

Changed main step

Old text 8. Execute Reusable State EVConnectedPostSession for EVSE.id = 2

Note(s):
If TxStopPoint contains one of the following values; Authorized, EnergyTransfer, PowerPathClosed, DataSigned.
Then the transaction will have ended at the EVConnectedPostSession state AND the Charging Station will
proceed with resetting itself. Proceed to step 10
Else proceed with step 9.
New text 8. Execute Reusable State EVConnectedPostSession for EVSE.id = 2

Note(s):
If TxStopPoint contains one of the following values; Authorized, EnergyTransfer, PowerPathClosed, DataSigned.
Then the transaction will have ended at the EVConnectedPostSession state AND the Charging Station will
proceed with resetting itself. Proceed to step 11
Else proceed with step 9.

6.1.8. Page 59 - (2023-12) - TC_B_26_CS - Removed rebooting step

The Charging Station does not reboot, when a reset EVSE is requested by the CSMS.

Removed main step

Removed 7. ChargingStation Reboots

Additionally requirement E07.FR.03 was removed from part 2 specification.

OCPP 2.0.1 - © Open Charge Alliance 2024 66/145 Edition 2 - Errata 2024-04
Old text Requirement(s) B12.FR.01, B12.FR.03 , E07.FR.03
New text Requirement(s) B12.FR.01, B12.FR.03

6.1.9. Page 64/66 - (2023-12) - TC_B_45_CS & TC_B_46_CS - Testcase has been
made more robust for Charging Stations that do not automatically reboot.
The testcase has been made more robust for Charging Stations that respond with Accepted, but do not automatically reboot.

Changed main step

Old text 5. The OCTT sends a ResetRequest

with type OnIdle

Note(s):
- This step will only be executed when the status RebootRequired is returned at step 4.
New text 5. The OCTT sends a ResetRequest
with type OnIdle

Note(s):
- This step will only be executed when the status RebootRequired is returned at step 4 , or if the charging does not
automatically reboot.

6.1.10. Page 68-72 - (2023-12) - TC_B_45_CS-TC_B_50_CS - Resolved testcase

inconsistency regarding used configuration slots
The testcase dynamically uses either configuration slot 1 or 2, based on the one that is currently connected. So the
configurationSlot and NetworkConfigurationPriority also needs to be set dynamically.

Changed main step

Old text 1. The OCTT sends a SetNetworkProfileRequest

with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot> depending on which
one is already in use
- connectionData.messageTimeout <Configured messageTimeout2>
- connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active>
- connectionData.ocppInterface <Configured ocppInterface2>
- connectionData.ocppVersion OCPP20
- connectionData.securityProfile <Configured securityProfile2>
New text 1. The OCTT sends a SetNetworkProfileRequest
with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot 2 > depending on which
one is already in use
- connectionData.messageTimeout <Configured messageTimeout> or <Configured messageTimeout2>
- connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active>
- connectionData.ocppInterface <Configured ocppInterface> or <Configured ocppInterface2>
- connectionData.ocppVersion OCPP20
- connectionData.securityProfile <Configured securityProfile2> or <Configured securityProfile2>

Changed main step

Old text 3. The OCTT sends a SetVariablesRequest

with variable.name is "NetworkConfigurationPriority"
component.name is "OCPPCommCtrlr"
attributeValue is <Configured configurationSlot2>

OCPP 2.0.1 - © Open Charge Alliance 2024 67/145 Edition 2 - Errata 2024-04
New text 3. The OCTT sends a SetVariablesRequest
with variable.name is "NetworkConfigurationPriority"
component.name is "OCPPCommCtrlr"
attributeValue is Configured slot from Step 1, the previously configured slot

6.1.11. Page 72 - (2023-12) - TC_B_50_CS - Testcase not only applicable for

AdditionalRootCertificateCheck = true
Note: An additional change to prerequisite(s) has been made by erratum: [Page 72 - (2024-02) - TC_B_50_CS - This testcase requires
that the Charging Station is connected with security profile 2 or 3]

This test case was conditional for feature AdditionalRootCertificateCheck, however this can always be performed (no relation with
AdditionalRootCertificateCheck).

Old text Prerequisite(s) - The Charging Station supports AS-2: AdditionalRootCertificateCheck.

- Configured (new) CSMS Root certificate 2 must be signed by the configured (old)
CSMS Root certificate 2.
- At least two configuration slots for networkConnectionProfiles must be supported
New text Prerequisite(s) At least two configuration slots for networkConnectionProfiles must be supported

Removed main steps

Removed 10. The OCTT sends a GetInstalledCertificateIdsRequest

with certificateType is CSMSRootCertificate

11. The Charging Station responds with a GetInstalledCertificateIdsResponse

Removed tool validation

Old text * Step 6:

Message ResetResponse
- status Accepted
* Step 11:
Message: GetInstalledCertificateIdsResponse
- status must be Accepted
- certificateHashDataChain must NOT contain an entry with following values:
- certificateType is CSMSRootCertificate
- certificateHashData contains <HashData from configured old CSMS Root certificate>
NOTE: The Charging Station dropped the (old) fallback certificate, because it was able to connect using the
(new) Root certificate.
New text * Step 6:
Message ResetResponse
- status Accepted

6.1.12. Page 72 - (2024-02) - TC_B_50_CS - This testcase requires that the

Charging Station is connected with security profile 2 or 3
It is logical that security profile 2 or 3 should be active to be able to execute this testcase, however this was not explicitly described.

Old text Prerequisite(s) At least two configuration slots for networkConnectionProfiles must be supported
New text Prerequisite(s) - At least two configuration slots for networkConnectionProfiles must be supported
AND
- The Charging Station must be connected using either security profile 2 or 3.

OCPP 2.0.1 - © Open Charge Alliance 2024 68/145 Edition 2 - Errata 2024-04
6.1.13. Page 77 - (2023-12) - TC_B_53_CS - Removed Component / variable list
It does not make sense to create a duplication of the component / variable list that is already defined in part 2 specification. This
will only increase the chance of inconsistencies.

Removed component / variable table

Changed post scenario validation

Old text OCTT checks that at least the following variables are reported:
New text The OCTT checks that the components / variables that are required according to the OCPP specification are
implemented.

6.1.14. Page 84 - (2024-04) - Local Stop Transaction - Different idToken

Test case has been improved. An AuthorizeRequest is expected, because Charging Station needs to request idTokenInfo to check
for a GroupId (C01.FR.02/03). Transaction must not be ended.

Test Case Id: TC_C_04_CS

Test case name Local Stop Transaction - Different idToken

Test case Id TC_C_04_CS
Use case Id(s) C01, C04, E07
Requirement(s) C01.FR.02, C01.FR.03
System under test Charging Station
Description The EV Driver tries to stop an ongoing transaction, by locally presenting a different IdToken.
Purpose To verify whether the Charging Station does not stop the charging session when a different idToken is
presented, than the one used to start the transaction.
Prerequisite(s) - The Charging Station supports at least one authorization method described at the following Use cases;
C01, C04.
- The Charging Station does NOT use one idToken reader for multiple EVSE.
- The Charging Station supports authorization methods other than NoAuthorization

Before Configuration State:

(Preparations) AuthCtrlr.AuthEnabled is true (If implemented AND ReadWrite)
AuthCtrlr.DisableRemoteAuthorization is false (If implemented)

Memory State:
- The "different idToken" does not exist in Authorization Cache or Local Authorization List.
- The "different idToken" does not have an associated GroupId that matches with the GroupId of the
"starting idToken".

Reusable State(s):
State is EnergyTransferStarted

Main Charging Station CSMS

(Test scenario) Manual Action: Present a different idToken than used to start the transaction.

1. The Charging Station sends an AuthorizeRequest

2. The OCTT responds with an AuthorizeResponse
with idTokenInfo.status Accepted

Note(s):
- The Charging Station SHALL NOT send an AuthorizeRequest AND/OR a TransactionEventRequest message
with an idToken field after receiving an idToken that is different, than the one used to start the transaction.
- The OCTT waits <Configured message timeout> seconds, before ending the testcase.

Tool validations N/a

Post scenario validations:

- Charging Station has not sent a TransactionEventRequest( Ended ).

OCPP 2.0.1 - © Open Charge Alliance 2024 69/145 Edition 2 - Errata 2024-04
6.1.15. Page 82-99 - (2023-12) - TC_C_02_CS-TC_C_57_CS - A number of test
cases cannot be run for a Charging Station that only supports NoAuthorization as a
local authorization option
We found that a number of test cases cannot be run for a Charging Station that only supports NoAuthorization as a local
authorization option (and it is not possible with the supported remote authorization options). Test cases for statuses like Invalid,
Authorization Cache, Local Auth. List, GroupId etc. will be dropped for this type of Charging Station implementation.

This erratum is applicable for the following testcases; TC_C_02_CS, TC_C_05_CS, TC_C_06_CS, TC_C_07_CS, TC_C_09_CS,
TC_C_10_CS, TC_C_11_CS, TC_C_34_CS, TC_C_36_CS, TC_C_39_CS, TC_C_44_CS, TC_C_45_CS, TC_C_47_CS, TC_C_48_CS,
TC_C_49_CS, TC_C_56_CS, TC_C_57_CS, TC_E_16_CS, TC_E_52_CS

Added Prerequisite(s) The Charging Station supports authorization methods other than NoAuthorization

6.1.16. Page 93 - (2023-12) - TC_C_15_CS - Improvements based on experience

from additional testing
During testing it was noticed that a value of 500 for MaxEnergyOnInvalidId is not enough. The scope of this testcase is to test that
the Charging Station does not deathorize the transaction.

Changed preparations

Old text Configuration State: AuthCacheCtrlr.AuthCacheEnabled is true (If implemented)

AuthCtrlr.LocalPreAuthorize is true (If implemented)
AuthCtrlr.LocalAuthorizeOffline is true
OfflineTxForUnknownIdEnabled is true (If implemented)
StopTxOnInvalidId is false
MaxEnergyOnInvalidId is 500
OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0
RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>
RetryBackOffRandomRange is 0
Note:
<Configured RetryBackOffWaitMinimum_duration should be long enough to execute
manual tasks>
New text Configuration State: AuthCacheCtrlr.AuthCacheEnabled is true (If implemented)
AuthCtrlr.LocalPreAuthorize is true (If implemented)
AuthCtrlr.LocalAuthorizeOffline is true
OfflineTxForUnknownIdEnabled is true (If implemented)
StopTxOnInvalidId is false
MaxEnergyOnInvalidId is 10.000
OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0
RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>
RetryBackOffRandomRange is 0
Note:
<Configured RetryBackOffWaitMinimum_duration should be long enough to execute
manual tasks>

Removed confusing main step. It was intended to describe the Charging Station shall not deathorize the transaction, as mentioned
by the tool validation section. But it is more clear to remove the steps as a whole from the main steps.

Removed main steps

Removed 5. The Charging Station sends a TransactionEventRequest with

triggerReason Deauthorized

6. The OCTT responds with a TransactionEventResponse

It is also not allowed for the Charging Station to stop the energy transfer.

OCPP 2.0.1 - © Open Charge Alliance 2024 70/145 Edition 2 - Errata 2024-04
Changed tool validation

Old text * Step 2:

Message TransactionEventRequest
A message with (optional):
- triggerReason Authorized
- idToken.idToken <Configured valid_idtoken_idtoken>
- idToken.type <Configured valid_idtoken_type>
- offline True
A message with:
- triggerReason ChargingStateChanged
- offline True
No message with:
- triggerReason Deauthorized or
- transactionInfo.chargingState SuspendedEVSE
New text * Step 3 :
Message TransactionEventRequest
A message with (optional):
- triggerReason Authorized
- idToken.idToken <Configured valid_idtoken_idtoken>
- idToken.type <Configured valid_idtoken_type>
- offline True
A message with:
- triggerReason ChargingStateChanged
- offline True
No message with:
- triggerReason Deauthorized or
- triggerReason ChargingStateChanged and
- transactionInfo.chargingState SuspendedEVSE

6.1.17. Page 101 - (2023-12) - TC_C_33_CS - Fixed broken table

The tool validations dropped of, because there was an Asciidoc issue. The table has been restored.

6.1.18. Page 104 - (2023-12) - TC_C_37_CS - Editorial issue

triggerReason Authorized should have been part of TransactionEventRequest, not TransactionEventResponse.

Changed main step

Old text 7. The Charging Station sends an TransactionEventRequest

8. The OCTT responds with an TransactionEventResponse with

triggerReason Authorized
New text 7. The Charging Station sends an TransactionEventRequest with
triggerReason Authorized

8. The OCTT responds with an TransactionEventResponse with

6.1.19. Page 87-97 and 168/169/170 - TC_E_43_CS/TC_E_44_CS/TC_E_45_CS and

Caching test cases - When a Charging Station supports ISO 15118 these test cases
need to be executed using EIM
For many test cases it does not matter if they’re run with Plug & charge or EIM, but there are test cases that (if supported) can only
be run with EIM.

OCPP 2.0.1 - © Open Charge Alliance 2024 71/145 Edition 2 - Errata 2024-04
Added note to test cases

Added NOTE: If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.

6.1.20. Page 129 - (2024-02) - TC_E_17_CS - Improved note regarding execution of

manual action present idToken
Changed note at main steps

Old text Manual Action: Present the IdToken that was used to start the transaction.

Note(s):
- This manual action needs to be executed when the Charging Station has a detachable cable on the Charging
Station side.
New text Manual Action: Present the IdToken that was used to start the transaction.

Note(s):
- This manual action needs to be executed when the Charging Station has a detachable cable on the Charging
Station side AND
UnlockOnEVSideDisconnect is set to false.

6.1.21. Page 131 - (2023-12) - TC_E_39_CS - Removed (local) indication on

Authorized reusable state
This testcase is also possible for remote authorization.

Changed preparations

Old text Reusable State(s): State is Authorized (local)

New text Reusable State(s): State is Authorized

6.1.22. Page 131 - (2023-12) - TC_E_39_CS - Made testcase more flexible to

handle all TxStart/StopPoint combinations
The testcase was only able to handle TxStart/StopPoint Authorized, but has been improved to also able to handle all other
TxStart/StopPoint combinations.

Changed main steps

Old text 1. The Charging Station sends a TransactionEventRequest

Note(s):
- This step needs to be executed after the <Configured ev_connection_timeout> expires, if the transaction has
been started. So in the case TxStartPoint contains ParkingBayOccupancy OR Authorized

2. The OCTT responds with a TransactionEventResponse

Note(s) : Optionally the Charging Station can send a StatusNotificationRequest or NotifyEventRequest with status
Available

OCPP 2.0.1 - © Open Charge Alliance 2024 72/145 Edition 2 - Errata 2024-04
New text 1. The Charging Station sends a TransactionEventRequest
Note(s):
- This step needs to be executed after the <Configured ev_connection_timeout> expires, if the transaction has
been started. So in the case TxStartPoint contains ParkingBayOccupancy OR Authorized

2. The OCTT responds with a TransactionEventResponse

Note(s) : Step 1 and 2 are optional and will only be expected when the TxStartPoint is set to ParkingBayOccupancy
or Authorized.
Optionally the Charging Station can send a StatusNotificationRequest or NotifyEventRequest with status
Available.

Manual Action : Connect the EV and EVSE on EV side.

Manual Action : Connect the EV and EVSE on EVSE side.

3. The Charging Station sends a TransactionEventRequest

Note(s) :
- This step needs to be executed after the <Configured ev_connection_timeout> expires, if the transaction has
been started. So in the case TxStartPoint contains ParkingBayOccupancy OR Authorized

4. The OCTT responds with a TransactionEventResponse

Note(s) :
Charging Station is allowed to sent a TransactionEventRequest for the cableplugin event when this is applicable,
but should not start charging.

Changed tool validation

Old text * Step 1:

Message: TransactionEventRequest
- triggerReason must be EVConnectTimeout
- eventType must be Ended
- transactionInfo.stoppedReason must be Timeout
New text * Step 1:
Message: TransactionEventRequest
- triggerReason must be EVConnectTimeout
- eventType must be Updated if TxStartPoint is ParkingBayOccupancy , else Ended
- transactionInfo.stoppedReason must be Timeout
* Step 3:
Message: TransactionEventRequest
- triggerReason can only be CablePluggedIn
- transactionInfo.chagringState should not be Charging
- eventType must be Updated if TxStartPoint is ParkingBayOccupancy , else Ended

6.1.23. Page 140 - (2024-04) - TC_E_37_CS - EVDisconnected and StoppedByEV

both allowed
If disconnecting charging cable is only possible by pressing a button on EV to unlock the cable the EV may already have stopped
the session before physically disconnecting the cable. In that case a StoppedByEV reason can be sent instead of EVDisconnected.

Test case name Stop transaction options - PowerPathClosed - EV side disconnect

Test case Id TC_E_37_CS
…

OCPP 2.0.1 - © Open Charge Alliance 2024 73/145 Edition 2 - Errata 2024-04
Test case name Stop transaction options - PowerPathClosed - EV side disconnect

Tool validations * Step 1:

Message: TransactionEventRequest
- triggerReason must be EVCommunicationLost
- transactionInfo.chargingState must be Idle
- transactionInfo.stoppedReason must be EVDisconnected or StoppedByEV (preferred value)
- eventType must be Ended

Post scenario validations:

N/a

6.1.24. Page 143 - (2023-12) - TC_E_14_CS - Explicitly describe it is allowed to

omit the stoppedReason in case of Local
The OCTT already allowed omitting the stoppedReason in case of Local as described by the specification, but part 6 did not
explicitly describe this.

Changed tool validation

Old text * Step 3:

Message: TransactionEventRequest
- triggerReason must be EVCommunicationLost
- transactionInfo.chargingState must be Idle
- If the OCTT is configured to stop transactions using a RequestStopTransactionRequest message then
transactionInfo.stoppedReason must be Remote
Else transactionInfo.stoppedReason must be Local or EVDisconnected
- eventType must be Ended
New text * Step 3:
Message: TransactionEventRequest
- triggerReason must be EVCommunicationLost
- transactionInfo.chargingState must be Idle
- If the OCTT is configured to stop transactions using a RequestStopTransactionRequest message then
transactionInfo.stoppedReason must be Remote
Else transactionInfo.stoppedReason must be Local, EVDisconnected or be omitted.
- eventType must be Ended

6.1.25. Page 153 - (2024-04) - TC_E_27_CS Update of prerequisites

Test case requires StopTxOnEvSideDisconnect to be set to false.

Test Case Id: TC_E_27_CS

Old Prerequisite(s) - The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is
text ReadOnly AND (the value Authorized OR ParkingBayOccupancy is NOT set OR (EnergyTransfer OR
PowerPathClosed OR DataSigned OR EVConnected is set)).
- If the mutability of TxStopPoint is _ReadWrite, then the value Authorized OR ParkingBayOccupancy
must be supported.
- The Charging Station has a permanently attached cable at the Charging Station side.
New Prerequisite(s) - The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is
text ReadOnly AND (the value Authorized OR ParkingBayOccupancy is NOT set OR (EnergyTransfer OR
PowerPathClosed OR DataSigned OR EVConnected is set)).
- If the mutability of TxStopPoint is _ReadWrite, then the value Authorized OR ParkingBayOccupancy
must be supported.
- The Charging Station has a permanently attached cable at the Charging Station side.
- StopTxOnEVSideDisconnect can be set to false .

OCPP 2.0.1 - © Open Charge Alliance 2024 74/145 Edition 2 - Errata 2024-04
6.1.26. Page 158 - (2023-12) - TC_E_31_CS - Made testcase more robust and
flexible regarding local / remote start/stop
Note: This erratum has been improved by erratum: [Page 158 - (2024-02) - TC_E_31_CS - Updated prerequisite description is
confusing]

The OCTT and testcases should be flexible. So it is now possible to run this testcase with a Charging Station that only supports
remote start/stop, however under very specific circumstances it is not possible to run this testcase with remote start/stop, as
described by below adjusted prerequisites.

Old text Prerequisite(s) The Charging Station supports at least one authorization method described at the
following Use cases; C01, C02, C04.
New text Prerequisite(s) The Charging Station supports at least one authorization method described at the
following Use cases; C01, C02, C04 and and the following configuration is not present:
- <configured scenario> is remote and
- TxStopPoint is Authorized and
- TxCtrlr.StopTxOnEVSideDisconnect is not true and cannot be configured that way.

The testcase has been made more robust. It now uses and takes into account the OCTT configuration Transaction duration.
Additionally the Sampled meter values are enabled to increase the chances of there being a TransactionEventRequest message in
the queue. With only the TransactionEventRequest with eventType = Ended in the queue, the Charging Station might empty its
queue a fraction of a second, before the OCTT is able to send the GetTransactionStatusRequest.

Changed preparations

Old text Configuration State: OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0

RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>
RetryBackOffRandomRange is 0
Note:
<Configured RetryBackOffWaitMinimum_duration> should be long enough to execute
manual tasks after waiting for <Configured Transaction Duration> seconds
New text Configuration State: SampledDataTxUpdatedMeasurands is <Configured
transaction_updated_metervalues_measurands>
SampledDataTxUpdatedInterval is <Configured
transaction_updated_metervalues_interval>
OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + <Configured
Transaction Duration> + 60.0
RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration> +
<Configured Transaction Duration>
RetryBackOffRandomRange is 0
Note:
<Configured Transaction Duration> should be long enough to execute manual tasks

The manual action to present the same idToken as used to start the transaction is only required if the OCTT is configured to run the
testcase in local authorization mode.

Added note to main step

Added Notes(s): Only if configured scenario is local

6.1.27. Page 158 - (2024-02) - TC_E_31_CS - Updated prerequisite description is

confusing
The updated prerequisite description by erratum Page 158 - (2023-12) - TC_E_31_CS - Made testcase more robust and flexible
regarding local / remote start/stop is confusing. With this errata it has been improved.

OCPP 2.0.1 - © Open Charge Alliance 2024 75/145 Edition 2 - Errata 2024-04
Old text Prerequisite(s) The Charging Station supports at least one authorization method described at the
following Use cases; C01, C02, C04 and and the following configuration is not present:
- <configured scenario> is remote and
- TxStopPoint is Authorized and
- TxCtrlr.StopTxOnEVSideDisconnect is not true and cannot be configured that way.
New text Prerequisite(s) The following combination of conditions are NOT true:
- No local authorization methods are supported AND
- TxStopPoint mutability is false and only contains Authorized AND
- TxCtrlr.StopTxOnEVSideDisconnect mutability is false and value is false
Note: If conditions 2 and 3 are true, but condition 1 is false, then please configure OCTT
configuration <scenario> as local.

6.1.28. Page 166/167 - (2023-12) - TC_E_42_CS & TC_E_51_CS - Refined the tool
validation of the testcase
No matter how high the configured MessageAttemptsTransactionEvent is, the OCTT will now this testcase passed after receiving
the second message. Another testcase will test the max retry count.

Changed tool validation

Old text * Step 5:

- Needs to be send a number of times equal to <Configured message_attempts_transaction_event> with an
interval of (<Configured message_attempts_transaction_event_interval> * the number of preceding
transmissions of this same message) + OCPPCommCtrlr.MessageTimeout.Default.
- The OCTT waits an additional MessageAttemptsTransactionEvent iteration where the interval is multiplied
again, to validate if the Charging Station stops resending the TransactionRequest message(s).
New text * Step 5:
- Needs to be sent 2 times with an interval of (<Configured message_attempts_transaction_event_interval> * the
number of preceding transmissions of this same message) + OCPPCommCtrlr.MessageTimeout.Default.
- The OCTT waits an additional MessageAttemptsTransactionEvent iteration where the interval is multiplied
again, to validate if the Charging Station stops resending the TransactionRequest message(s).

6.1.29. Page 174 - (2023-12) - TC_F_04_CS - Missing prerequisite

This testcase is only applicable if the Charging Station supports either TxStartPoint Authorized or ParkingBayOccupancy. Otherwise
the Charging Station will not have started a transaction. So in that case the OCTT won’t be able to verify the
TransactionEventRequest with eventType Ended.

Old text Prerequisite(s) N/a

New text Prerequisite(s) The Charging Station supports TxCtrlr.TxStartPoint ParkingBayOccupancy OR
Authorized .

6.1.30. Page 207 - (2023-12) - TC_G_13_CS - Charging Station does not have to
report the status of the connector
The availability is being set from Inoperative to Inoperative, therefore it is not needed for the Charging Station to report the status of
the connector to the CSMS, because there was no status change.

Changed main steps

Old text 3. The Charging Station notifies the CSMS about the current state of all connectors.
4. The OCTT responds accordingly.
New text Note : It is not needed for the Charging Station to report the status of the connector to the CSMS, because there
was no status change.

Changed tool validation

OCPP 2.0.1 - © Open Charge Alliance 2024 76/145 Edition 2 - Errata 2024-04
Old text * Step 2:
Message ChangeAvailabilityResponse
- status Accepted
* Step 3:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "ChargingStation"
- eventData[0].variable.name "AvailabilityState"
New text * Step 2:
Message ChangeAvailabilityResponse
- status Accepted

6.1.31. Page 217/219/223 - (2023-12) - TC_J_01_CS & TC_J_02_CS & TC_J_06_CS

- It is currently not possible to send a NotifyEventRequest instead of a
MeterValuesRequest
Part 2 specification describes that the StatusNotificationRequest and the MeterValuesRequest will be moved to the device model
at some point and it can be transmitted via a NotifyEventRequest. As for the StatusNotificationRequest, this is already described
how to do this, so the OCTT will expect a Charging Station to send NotifyEventRequest messages instead. However as for the
MeterValuesRequest, it was noticed that this is not clearly described. The different measurands need to transmitted using several
different components and variables. Therefore it is not allowed to send these instead of the MeterValuesRequest messages,
however it is allowed to send them in parallel.

Changed tool validation

Old text * Step 1:

Message: MeterValuesRequest
- sampledValue[0].context must be Sample.Clock
- sampledValue must contain <An element per configured measurand at the AlignedDataMeasurands. The
measurand field may be omitted when the measurand is "Energy.Active.Import.Register">
Message: NotifyEventRequest
- eventData must contain <An element per configured measurand at the AlignedDataMeasurands.>
- trigger must be Periodic
- component.name must be "FiscalMetering"
Note: The following tool validation will NOT be validated by the OCTT:
- variable.name must <Refer to the configured measurand in PascalCase without a "." in between. For example;
"EnergyActiveImportRegister">
New text * Step 1:
Message: MeterValuesRequest
- sampledValue[0].context must be Sample.Clock
- sampledValue must contain <An element per configured measurand at the AlignedDataMeasurands. The
measurand field may be omitted when the measurand is "Energy.Active.Import.Register">
Note: The following tool validation will NOT be validated by the OCTT:
- variable.name must <Refer to the configured measurand in PascalCase without a "." in between. For example;
"EnergyActiveImportRegister">

Changed post scenario validation

OCPP 2.0.1 - © Open Charge Alliance 2024 77/145 Edition 2 - Errata 2024-04
Old text Message: MeterValuesRequest
- timestamp <The intervals between the timestamps of the received Meter Value messages must equal the
configured value at AlignedDataInterval. However it is allowed to send multiple Meter Value messages per
configured interval. One (or more in case the amount of measured data is too much for one message) for each
EVSE and one (or more) for the main power meter (evseId=0). But the timestamp of these messages must all be
the same.>
Message: NotifyEventRequest
- timestamp <The intervals between the timestamps of the received Meter Value messages must equal the
configured value at AlignedDataInterval. However it is allowed to send multiple Meter Value messages per
configured interval. One (or more in case the amount of measured data is too much for one message) for each
EVSE and one (or more) for the main power meter (evseId=0). But the timestamp of these messages must all be
the same.>
New text Message: MeterValuesRequest
- timestamp <The intervals between the timestamps of the received Meter Value messages must equal the
configured value at AlignedDataInterval. However it is allowed to send multiple Meter Value messages per
configured interval. One (or more in case the amount of measured data is too much for one message) for each
EVSE and one (or more) for the main power meter (evseId=0). But the timestamp of these messages must all be
the same.>

OCPP 2.0.1 - © Open Charge Alliance 2024 78/145 Edition 2 - Errata 2024-04
6.1.32. Page 226 - (2024-04) - Context Transaction.Begin used once evseId is
known
This test case assumed that a Charging Station with multiple EVSEs will send meter values for Transaction.Begin in a
TransactionEvent(Updated) message after plug-in. This would only apply to multiple EVSEs. It has now been made more generic.
The first time when the TransactionEvent reports the field evse the test case expects meter values for Transaction.Begin.

Table 5. Test Case Id: TC_J_08_CS

Test case name Sampled Meter Values - Context Transaction.Begin - EVSE not known
Test case Id TC_J_08_CS
Use case Id(s) J02 & (E01,E02,E03,E09,E04,E05)
Requirement(s) J02.FR.01, J02.FR.02, J02.FR.03, J02.FR.04, J02.FR.10, E01.FR.16 , E01.FR.17, E03.FR.11, E04.FR.11,
E05.FR.08
System under test Charging Station
Description The Charging Station samples the electrical meter or other sensor/transducer hardware to provide
information about its Meter Values. Depending on configuration settings, the Charging Station will send
Meter Values.
Purpose To verify if the Charging Station sends Meter Values for Transaction.Begin as soon as the EVSE to be used
is known, for a transaction that starts before the cable is plugged in.
Prerequisite(s) - The Charging Station has an energy meter.
- The Charging Station does NOT have the following configuration; TxStartPoint does NOT contain
ParkingBayOccupancy OR Authorized.
- Test case is only applicable when the Charging Station has more than 1 EVSE.

Before Configuration State:

(Preparations) TxStartPoint contains Authorized
Note: TxStartPoint contains Authorized AND/OR ParkingBayOccupancy (At least one of these values must
be set).

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. Execute Reusable State EnergyTransferStarted

Tool validations N/a

Post scenario validations:

- The first TransactionEventRequest containing a value for evse , sent during the execution of reusable state
EVConnectedPreSession contains the MeterValue field with:
- sampledValue[0].context must be Transaction.Begin
- sampledValue must contain <An element per configured measurand at the
SampledDataTxStartedMeasurands. The measurand field may be omitted when the measurand is
"Energy.Active.Import.Register">

6.1.33. Page 232-265 - (2023-12) - TC_L_XX_CS - Update testcase structure L

group testcases
Note: The part of this erratum regarding TC_L_08_CS has been updated by: [Page 245 - (2024-02) - TC_L_08_CS - Resolved issues
after L test cases rewrite]

The structure of almost all 'Secure Firmware Update' testcases have been updated. There were several reasons for this. Please
note that this has mostly been done for readability. Functional changes that have been made, were mostly to increase the flexibility
needed to comply with the requirements and all possible firmware update process paths defined at part 2. Please refer to Part 2
specification Figure 119. Firmware update process, for the overview.

Table 6. Test Case Id: TC_L_01_CS

Test case name Secure Firmware Update - Installation successful
Test case Id TC_L_01_CS

OCPP 2.0.1 - © Open Charge Alliance 2024 79/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Installation successful
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.04,L01.FR.05,L01.FR.09,L01.FR.10,L01.FR.12,L01.FR.13,L01.FR.15,L01.FR.20,L01.FR.21,L
01.FR.23
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to securely download and install a new firmware.
Prerequisite(s) A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.

Before Configuration State:

(Preparations) N/a

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours>
firmware.location <Configured firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station notifies the CSMS about the
current state of all connectors. 10. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its connectors to Unavailable, before
proceeding installing the new firmware.

11. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
12. The Charging Station sends a
FirmwareStatusNotificationRequest 13. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 11.

OCPP 2.0.1 - © Open Charge Alliance 2024 80/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Installation successful

14. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

15. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 16 through 21 can be send in a different order.
16. The Charging Station notifies the CSMS about
the current state of all connectors. 17. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
9) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 11 or 14) yet.
18. The Charging Station sends a
FirmwareStatusNotificationRequest 19. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
20. The Charging Station sends a
SecurityEventNotificationRequest 21. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 81/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Installation successful

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 12:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 16:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 18:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 20:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 82/145 Edition 2 - Errata 2024-04
Table 7. Test Case Id: TC_L_02_CS
Test case name Secure Firmware Update - InstallScheduled
Test case Id TC_L_02_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.04,L01.FR.05,L01.FR.09,L01.FR.10,L01.FR.12,L01.FR.15,L01.FR.16,L01.FR.20,L01.FR.21,L
01.FR.23
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able securely download a new firmware and schedule its installation.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The OCTT configuration firmware installDateTime needs to set to a future dateTime.

Before Configuration State:

(Preparations) N/a

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.location <Configured
UpdateFirmwareResponse firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
firmware.installDateTime <Current DateTime +
<Configured Install Offset Period>>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest 10. The OCTT responds with a
With status InstallScheduled FirmwareStatusNotificationResponse

Note(s):
- The Charging Station will start installing the firmware
after the set installDateTime is reached.
11. The Charging Station notifies the CSMS about
the current state of all connectors. 12. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its connectors to Unavailable, before
proceeding installing the new firmware.

OCPP 2.0.1 - © Open Charge Alliance 2024 83/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - InstallScheduled

13. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
14. The Charging Station sends a
FirmwareStatusNotificationRequest 15. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 13.

16. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

17. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 18 through 23 can be send in a different order.
18. The Charging Station notifies the CSMS about
the current state of all connectors. 19. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
11) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 13 or 16) yet.
20. The Charging Station sends a
FirmwareStatusNotificationRequest 21. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
22. The Charging Station sends a
SecurityEventNotificationRequest 23. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 84/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - InstallScheduled

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message FirmwareStatusNotificationRequest
- status InstallScheduled
* Step 11:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 14:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 18:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 20:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 22:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 85/145 Edition 2 - Errata 2024-04
Table 8. Test Case Id: TC_L_03_CS
Test case name Secure Firmware Update - DownloadScheduled
Test case Id TC_L_03_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.04,L01.FR.05,L01.FR.09,L01.FR.10,L01.FR.12,L01.FR.13,L01.FR.15,L01.FR.20,L01.FR.21,L
01.FR.23
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to schedule securely downloading a new firmware.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The OCTT configuration firmware retrieveDateTime needs to set to a future dateTime.

Before Configuration State:

(Preparations) N/a

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours>
firmware.location <Configured firmware_location>
firmware.retrieveDateTime <Current DateTime +
<Configured Download Offset Period>>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status DownloadScheduled FirmwareStatusNotificationResponse

Note(s):
- The Charging Station will start downloading the
firmware after the set retrieveDateTime is reached.
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest 10. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
11. The Charging Station notifies the CSMS about
the current state of all connectors. 12. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its connectors to Unavailable, before
proceeding installing the new firmware.

OCPP 2.0.1 - © Open Charge Alliance 2024 86/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - DownloadScheduled

13. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
14. The Charging Station sends a
FirmwareStatusNotificationRequest 15. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 13.

16. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

17. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 18 through 23 can be send in a different order.
18. The Charging Station notifies the CSMS about
the current state of all connectors. 19. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
11) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 13 or 16) yet.
20. The Charging Station sends a
FirmwareStatusNotificationRequest 21. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
22. The Charging Station sends a
SecurityEventNotificationRequest 23. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 87/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - DownloadScheduled

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status DownloadScheduled
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 7:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 9:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 11:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 14:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 18:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 20:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 22:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 88/145 Edition 2 - Errata 2024-04
Table 9. Test Case Id: TC_L_06_CS
Test case name Secure Firmware Update - InvalidSignature
Test case Id TC_L_06_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.03,L01.FR.04,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to identify if the signature is invalid and report this to the CSMS.
Prerequisite(s) A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.

Before Configuration State:

(Preparations) <Configured invalid firmware signature> should be a real signature

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours>
firmware.location <Configured firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured invalid firmware
signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest. 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse.
5. The Charging Station sends a
FirmwareStatusNotificationRequest. 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse.
7. The Charging Station sends a
FirmwareStatusNotificationRequest. 8. The OCTT responds with a
With status InvalidSignature FirmwareStatusNotificationResponse.
9. The Charging Station sends a
SecurityEventNotificationRequest. 10. The OCTT responds with a
With type InvalidFirmwareSignature SecurityEventNotificationResponse.

OCPP 2.0.1 - © Open Charge Alliance 2024 89/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - InvalidSignature

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status InvalidSignature
* Step 9:
Message SecurityEventNotificationRequest
- type InvalidFirmwareSignature

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 90/145 Edition 2 - Errata 2024-04
Table 10. Test Case Id: TC_L_07_CS
Test case name Secure Firmware Update - DownloadFailed
Test case Id TC_L_07_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to report to the CSMS when it is unable to download the new
firmware.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The at the OCTT configured invalid firmware location needs to point to a not existing firmware file name.

Before Configuration State:

(Preparations) N/a

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours>
firmware.location <Configured firmware location> +
"_does_not_exist"
firmware.retrieveDateTime _<Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest. 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse.

Note(s):
- This step is optional. The Charging Station may
immediately identify downloading the firmware is not
possible.
5. The Charging Station sends a
FirmwareStatusNotificationRequest. 6. The OCTT responds with a
With status DownloadFailed FirmwareStatusNotificationResponse.

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status DownloadFailed

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 91/145 Edition 2 - Errata 2024-04
Table 11. Test Case Id: TC_L_08_CS
Test case name Secure Firmware Update - InstallVerificationFailed or InstallationFailed
Test case Id TC_L_08_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.10,L01.FR.12,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to report to the CSMS when the firmware verification fails.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The at the OCTT configured invalid firmware location needs to point to a firmware file that causes an
InstallVerificationFailed.

Before Configuration State:

(Preparations) <Configured invalid firmware location> should point to existing firmware that causes an
InstallVerificationFailed
<Configured invalid firmware signingCertificate> should be a trusted signingCertificate
<Configured invalid firmware signature> should be a real signature

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours>
firmware.location <Configured invalid firmware
location>
firmware.retrieveDateTime <Current DateTime +
<Current DateTime - 2 hours>>
firmware.signingCertificate <Configured invalid
firmware signingCertificate>
firmware.signature <Configured invalid firmware
signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station notifies the CSMS about the
current state of all connectors. 10. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its connectors to Unavailable, before
proceeding installing the new firmware.

11. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.

OCPP 2.0.1 - © Open Charge Alliance 2024 92/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - InstallVerificationFailed or InstallationFailed
12. The Charging Station sends a
FirmwareStatusNotificationRequest 13. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 11.

14. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

15. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 16 through 21 can be send in a different order.
16. The Charging Station notifies the CSMS about
the current state of all connectors. 17. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
9) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 11 or 14) yet.
18. The Charging Station sends a
FirmwareStatusNotificationRequest 19. The OCTT responds with a
With status InstallVerificationFailed or FirmwareStatusNotificationResponse
InstallationFailed
20. The Charging Station sends a
SecurityEventNotificationRequest 21. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 93/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - InstallVerificationFailed or InstallationFailed

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 12:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 16:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 18:
Message FirmwareStatusNotificationRequest
- status InstallVerificationFailed or InstallationFailed
* Step 20:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 94/145 Edition 2 - Errata 2024-04
Table 12. Test Case Id: TC_L_10_CS
Test case name Secure Firmware Update - AcceptedCanceled
Test case Id TC_L_10_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.10,L01.FR.20,L01.FR.24
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to cancel an ongoing firmware update and start a new one, when
receiving an UpdateFirmwareRequest from the CSMS.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The Charging Station is able to cancel an ongoing firmware update while it is busy downloading a new
firmware file.

Before Configuration State:

(Preparations) N/a

Memory State:
N/a

Reusable State(s):
N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 95/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - AcceptedCanceled

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse

5. The OCTT sends a UpdateFirmwareRequest

6. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status AcceptedCanceled firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest 10. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
11. The Charging Station sends a
FirmwareStatusNotificationRequest 12. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
13. The Charging Station notifies the CSMS about
the current state of all connectors. 14. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its connectors to Unavailable, before
proceeding installing the new firmware.

15. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
16. The Charging Station sends a
FirmwareStatusNotificationRequest 17. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 15.

18. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

OCPP 2.0.1 - © Open Charge Alliance 2024 96/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - AcceptedCanceled

19. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 20 through 25 can be send in a different order.
20. The Charging Station notifies the CSMS about
the current state of all connectors. 21. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
13) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 15 or 18) yet.
22. The Charging Station sends a
FirmwareStatusNotificationRequest 23. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
24. The Charging Station sends a
SecurityEventNotificationRequest 25. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 97/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - AcceptedCanceled

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 6:
Message UpdateFirmwareResponse
- status AcceptedCanceled
(The requestId at the FirmwareStatusNotificationRequest messages must refer to the one from the second
UpdateFirmwareRequest from this point on).
* Step 7:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 9:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 11:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 13:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 16:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 20:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 22:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 24:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 98/145 Edition 2 - Errata 2024-04
Table 13. Test Case Id: TC_L_11_CS
Test case name Secure Firmware Update - Unable to cancel
Test case Id TC_L_11_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.10,L01.FR.20,L01.FR.27
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to reject a firmware update request when it is unable to cancel an
ongoing firmware update.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The Charging Station is NOT able to cancel an ongoing firmware update.

Before Configuration State:

(Preparations) N/a

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse

5. The OCTT sends a UpdateFirmwareRequest

6. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Rejected firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest 10. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
11. The Charging Station notifies the CSMS about
the current state of all connectors. 12. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its connectors to Unavailable, before
proceeding installing the new firmware.

OCPP 2.0.1 - © Open Charge Alliance 2024 99/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to cancel

13. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
14. The Charging Station sends a
FirmwareStatusNotificationRequest 15. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 13.

16. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

17. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 18 through 23 can be send in a different order.
18. The Charging Station notifies the CSMS about
the current state of all connectors. 19. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
11) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 13 or 16) yet.
20. The Charging Station sends a
FirmwareStatusNotificationRequest 21. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
22. The Charging Station sends a
SecurityEventNotificationRequest 23. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 100/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to cancel

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 6:
Message UpdateFirmwareResponse
- status Rejected
* Step 7:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 9:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 11:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 14:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 18:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 20:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 22:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 101/145 Edition 2 - Errata 2024-04
Table 14. Test Case Id: TC_L_12_CS
Test case name Secure Firmware Update - Unable to download/install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true
Test case Id TC_L_12_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to keep allowing new transactions when requested to update the
firmware, while there is an ongoing transaction.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The Charging Station is able to start more than one transaction at a time.
- The Charging Station is unable to download AND install firmware while there is an ongoing transaction.

Before Configuration State:

(Preparations) AllowNewSessionsPendingFirmwareUpdate is true (If implemented)

Memory State:
N/a

Reusable State(s):
State is EnergyTransferStarted for <Configured connectorId>

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status DownloadScheduled FirmwareStatusNotificationResponse

5. Execute Reusable State EnergyTransferStarted for <Configured second Connector>

Note(s):
- It is allowed to start a second transaction while there is a scheduled firmware update.

6. Execute Reusable State ParkingBayUnoccupied for <Configured connectorId>

Note(s):
- The Charging Station will proceed to this end state. This will cause the transaction to stop.

7. Execute Reusable State ParkingBayUnoccupied for <Configured second Connector>

Note(s):
- The Charging Station will proceed to this end state. This will cause the transaction to stop.
- The Charging Station will start the firmware update process the moment this second transaction ends or
when all interactions with the EV Driver are done (So after the cable has been unplugged, if there is no parking
bay sensor).

OCPP 2.0.1 - © Open Charge Alliance 2024 102/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to download/install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true
8. The Charging Station sends a
FirmwareStatusNotificationRequest 9. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
10. The Charging Station sends a
FirmwareStatusNotificationRequest 11. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
12. The Charging Station sends a
FirmwareStatusNotificationRequest 13. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
14. The Charging Station notifies the CSMS about
the current state of all connectors. 15. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its connectors to Unavailable, before
proceeding installing the new firmware.

16. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
17. The Charging Station sends a
FirmwareStatusNotificationRequest 18. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 16.

19. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

OCPP 2.0.1 - © Open Charge Alliance 2024 103/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to download/install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

20. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 21 through 26 can be send in a different order.
21. The Charging Station notifies the CSMS about
the current state of all connectors. 22. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
14) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 16 or 19) yet.
23. The Charging Station sends a
FirmwareStatusNotificationRequest 24. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
25. The Charging Station sends a
SecurityEventNotificationRequest 26. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 104/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to download/install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status DownloadScheduled
* Step 8:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 10:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 12:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 14:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 17:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 21:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 23:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 25:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 105/145 Edition 2 - Errata 2024-04
Table 15. Test Case Id: TC_L_13_CS
Test case name Secure Firmware Update - Unable to download/install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false
Test case Id TC_L_13_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to set its available connectors to Unavailable when requested to
update the firmware, while there is an ongoing transaction.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The configuration variable AllowNewSessionsPendingFirmwareUpdate is implemented.
- The Charging Station is unable to download AND install firmware while there is an ongoing transaction.

Before Configuration State:

(Preparations) AllowNewSessionsPendingFirmwareUpdate is false

Memory State:
N/a

Reusable State(s):
State is EnergyTransferStarted

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status DownloadScheduled FirmwareStatusNotificationResponse

Note: This step is optional. Part 2 specification only

describes that this status needs to be send in case
the retrieveDateTime is in the future. However it is
also allowed to send this status if the Charging
Station schedules the firmware download, because of
an ongoing transaction.
5. The Charging Station notifies the CSMS about the
current state of its Available connector(s). 6. The OCTT responds accordingly.

Note(s):
- This step needs to be executed for all connectors
with AvailabilityState Available.

7. Execute Reusable State ParkingBayUnoccupied for <Configured connectorId>

Note(s):
- The Charging Station will proceed to this end state. This will cause the transaction to stop.
- The Charging Station will start the firmware update process the moment the transaction ends or when all
interactions with the EV Driver are done (So after the cable has been unplugged, if there is no parking bay
sensor).

OCPP 2.0.1 - © Open Charge Alliance 2024 106/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to download/install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false
8. The Charging Station sends a
FirmwareStatusNotificationRequest 9. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
10. The Charging Station sends a
FirmwareStatusNotificationRequest 11. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
12. The Charging Station sends a
FirmwareStatusNotificationRequest 13. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
14. The Charging Station notifies the CSMS about
the current state of all connectors. 15. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its last connector also to Unavailable,
before proceeding installing the new firmware.

16. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
17. The Charging Station sends a
FirmwareStatusNotificationRequest 18. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 16.

19. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

OCPP 2.0.1 - © Open Charge Alliance 2024 107/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to download/install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

20. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 21 through 26 can be send in a different order.
21. The Charging Station notifies the CSMS about
the current state of all connectors. 22. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
14) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 16 or 19) yet.
23. The Charging Station sends a
FirmwareStatusNotificationRequest 24. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
25. The Charging Station sends a
SecurityEventNotificationRequest 26. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 108/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to download/install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status DownloadScheduled
* Step 5:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 8:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 10:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 12:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 14:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 17:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 21:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 23:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 25:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 109/145 Edition 2 - Errata 2024-04
Table 16. Test Case Id: TC_L_14_CS
Test case name Secure Firmware Update - Unable to install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true
Test case Id TC_L_14_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to keep allowing new transactions when requested to update the
firmware, while there is an ongoing transaction.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The Charging Station is able to start more than one transaction at a time.
- The Charging Station is unable to install firmware while there is an ongoing transaction.

Before Configuration State:

(Preparations) AllowNewSessionsPendingFirmwareUpdate is true (If implemented)

Memory State:
N/a

Reusable State(s):
State is EnergyTransferStarted for EVSEId 1 and ConnectorId 1

OCPP 2.0.1 - © Open Charge Alliance 2024 110/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest 10. The OCTT responds with a
With status InstallScheduled FirmwareStatusNotificationResponse

11. Execute Reusable State EnergyTransferStarted for <Configured second Connector>

Note(s):
- It is allowed to start a second transaction while there is a scheduled firmware update.

12. Execute Reusable State ParkingBayUnoccupied for <Configured connectorId>

Note(s):
- The Charging Station will proceed to this end state. This will cause the transaction to stop.

13. Execute Reusable State ParkingBayUnoccupied for <Configured second Connector>

Note(s):
- The Charging Station will proceed to this end state. This will cause the transaction to stop.
- The Charging Station will start the firmware update process the moment this second transaction ends or
when all interactions with the EV Driver are done (So after the cable has been unplugged, if there is no parking
bay sensor).
14. The Charging Station notifies the CSMS about
the current state of all connectors. 15. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its connectors to Unavailable, before
proceeding installing the new firmware.

16. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.

OCPP 2.0.1 - © Open Charge Alliance 2024 111/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true
17. The Charging Station sends a
FirmwareStatusNotificationRequest 18. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 16.

19. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

20. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 21 through 26 can be send in a different order.
21. The Charging Station notifies the CSMS about
the current state of all connectors. 22. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
14) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 16 or 19) yet.
23. The Charging Station sends a
FirmwareStatusNotificationRequest 24. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
25. The Charging Station sends a
SecurityEventNotificationRequest 26. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 112/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message FirmwareStatusNotificationRequest
- status InstallScheduled
* Step 14:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 17:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 21:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 23:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 25:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 113/145 Edition 2 - Errata 2024-04
Table 17. Test Case Id: TC_L_15_CS
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false
Test case Id TC_L_15_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to set its available connectors to Unavailable when requested to
update the firmware, while there is an ongoing transaction.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The configuration variable AllowNewSessionsPendingFirmwareUpdate is implemented.
- The Charging Station is unable to install firmware while there is an ongoing transaction.

Before Configuration State:

(Preparations) AllowNewSessionsPendingFirmwareUpdate is false

Memory State:
N/a

Reusable State(s):
State is EnergyTransferStarted

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest 10. The OCTT responds with a
With status InstallScheduled FirmwareStatusNotificationResponse

Note: This step is optional. Part 2 specification only

describes that this status needs to be send in case
the installDateTime is in the future. However it is also
allowed to send this status if the Charging Station
schedules the firmware installation, because of an
ongoing transaction.
11. The Charging Station notifies the CSMS about
the current state of its Available connector(s). 12. The OCTT responds accordingly.

Note(s):
- This step needs to be executed for all connectors
with AvailabilityState Available.

OCPP 2.0.1 - © Open Charge Alliance 2024 114/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

13. Execute Reusable State ParkingBayUnoccupied for <Configured connectorId>

Note(s):
- The Charging Station will proceed to this end state. This will cause the transaction to stop.
- The Charging Station will start the firmware update process the moment the transaction ends or when all
interactions with the EV Driver are done (So after the cable has been unplugged, if there is no parking bay
sensor).
14. The Charging Station notifies the CSMS about
the current state of all connectors. 15. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its last connector to Unavailable, before
proceeding installing the new firmware.

16. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
17. The Charging Station sends a
FirmwareStatusNotificationRequest 18. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 16.

19. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

20. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 21 through 26 can be send in a different order.
21. The Charging Station notifies the CSMS about
the current state of all connectors. 22. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
14) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 16 or 19) yet.
23. The Charging Station sends a
FirmwareStatusNotificationRequest 24. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
25. The Charging Station sends a
SecurityEventNotificationRequest 26. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 115/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message FirmwareStatusNotificationRequest
- status InstallScheduled
* Step 11:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 14:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 17:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 21:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 23:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 25:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 116/145 Edition 2 - Errata 2024-04
Table 18. Test Case Id: TC_L_16_CS
Test case name Secure Firmware Update - Able to update firmware with ongoing transaction
Test case Id TC_L_16_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.06,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to securely download and install a new firmware, while a transaction
is ongoing.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The Charging Station is able to update its firmware while a transaction is ongoing.

Before Configuration State:

(Preparations) N/a

Memory State:
N/a

Reusable State(s):
State is EnergyTransferStarted

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours>
firmware.location <Configured firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest. 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse.
5. The Charging Station sends a
FirmwareStatusNotificationRequest. 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse.
7. The Charging Station sends a
FirmwareStatusNotificationRequest. 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse.
9. The Charging Station sends a
FirmwareStatusNotificationRequest. 10. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse.

11. The OCTT waits for the Charging Station to reconnect.

Note: The Charging Station reconnects to reestablish the protocol version handshake.
12. The Charging Station sends a
FirmwareStatusNotificationRequest. 13. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse.
14. The Charging Station sends a
SecurityEventNotificationRequest 15. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 117/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Able to update firmware with ongoing transaction

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 12:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 14:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 118/145 Edition 2 - Errata 2024-04
Table 19. Reusable State: RebootBeforeFirmwareInstallation
State RebootBeforeFirmwareInstallation
System under test Charging Station
Description The Charging Station needs to reboot before firmware installation.

Before Configuration State:

(Preparations) N/a

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The Charging Station sends a
FirmwareStatusNotificationRequest 2. The OCTT responds with a
With status InstallRebooting FirmwareStatusNotificationResponse
Note: The steps 3 through 8 are only executed if the bootloader is able to communicate OCPP.
3. The Charging Station sends a
BootNotificationRequest 4. The OCTT responds with a
BootNotificationResponse
with status Accepted
5. The Charging Station notifies the CSMS about the
current state of all connectors. 6. The OCTT responds accordingly.
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Tool validations * Step 1:

Message FirmwareStatusNotificationRequest
- status InstallRebooting
* Step 3:
Message BootNotificationRequest
- reason FirmwareUpdate
* Step 7:
Message FirmwareStatusNotificationRequest
- status Installing

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 119/145 Edition 2 - Errata 2024-04
Table 20. Reusable State: RebootBeforeFirmwareActivation
State RebootBeforeFirmwareActivation
System under test Charging Station
Description The Charging Station needs to reboot before firmware activation.

Before Configuration State:

(Preparations) N/a

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The Charging Station sends a
FirmwareStatusNotificationRequest 2. The OCTT responds with a
With status InstallRebooting FirmwareStatusNotificationResponse

Note(s):
- This step is optional. However it is recommended to
notify the CSMS before rebooting the Charging Station
to activate the new firmware.
3. The Charging Station sends a
BootNotificationRequest 4. The OCTT responds with a
BootNotificationResponse
with status Accepted
5. The Charging Station notifies the CSMS about the
current state of all connectors. 6. The OCTT responds accordingly.

Tool validations * Step 1:

Message FirmwareStatusNotificationRequest
- status InstallRebooting
* Step 3:
Message BootNotificationRequest
- reason FirmwareUpdate

Post scenario validations:

N/a

6.1.34. Page 241 - (2023-12) - TC_L_05_CS - Added main step and tool validation
for SecurityEventNotification InvalidFirmwareSigningCertificate
During additional testing it was noticed that this testcase should also have been expecting a SecurityEventNotification of type
InvalidFirmwareSigningCertificate, in accordance with requirement L01.FR.02.

Additionally, the testcase now uses a generated invalid certificate, instead of the tester needing the configure one, to improve the
ease of use of the OCTT.

Added main steps

Added 3. The Charging Station sends a SecurityEventNotificationRequest.

With type InvalidFirmwareSigningCertificate
4. The OCTT responds with a SecurityEventNotificationResponse.

Added tool validation

Added * Step 3:
Message SecurityEventNotificationRequest
- type InvalidFirmwareSigningCertificate

OCPP 2.0.1 - © Open Charge Alliance 2024 120/145 Edition 2 - Errata 2024-04
6.1.35. Page 245 - (2024-02) - TC_L_08_CS - Resolved issues after L test cases
rewrite
Note: This erratum resolves the issues introduced at erratum: [Page 232-265 - (2023-12) - TC_L_XX_CS - Update testcase structure L
group testcases]

During the L test cases rewrite, this firmware update failure testcase reused too much text from the firmware update success test
cases.

Removed main steps

The reboot and reconnect described at these steps are only applicable in case of a successful firmware update.

Removed 14. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

15. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point. The
Charging Station should at least reconnect to reestablish the protocol version handshake.

Removed main steps

This securityEventNotification must only be sent in case of a successful firmware update.

Removed 20. The Charging Station sends a SecurityEventNotificationRequest

With type FirmwareUpdated

21. The OCTT responds with a SecurityEventNotificationResponse

Changed note main step 16 (renumbered to step 14)

Old text Note(s):

- This step only needs to be executed if the connectors were previously set to Unavailable (at step 9) and the
Charging Station did not report setting them back to Available (after the reboot sequence at step 11) yet.
New text Note(s):
- This step only needs to be executed if the connectors were previously set to Unavailable (at step 9) and the
Charging Station did not report setting them back to Available (after the reboot sequence at step 11) yet.
- And if the Charging Station did not become inoperative after the firmware update failure. It is recommended for a
Charging Station to fallback to the previous firmware after a firmware update failure.

Updated version of the complete testcase

Table 21. Test Case Id: TC_L_08_CS

Test case name Secure Firmware Update - InstallVerificationFailed or InstallationFailed
Test case Id TC_L_08_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.10,L01.FR.12,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate.
Purpose To verify if the Charging Station is able to report to the CSMS when the firmware verification fails.

OCPP 2.0.1 - © Open Charge Alliance 2024 121/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - InstallVerificationFailed or InstallationFailed
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The at the OCTT configured invalid firmware location needs to point to a firmware file that causes an
InstallVerificationFailed.

Before Configuration State:

(Preparations) <Configured invalid firmware location> should point to existing firmware that causes an
InstallVerificationFailed
<Configured invalid firmware signingCertificate> should be a trusted signingCertificate
<Configured invalid firmware signature> should be a real signature

Memory State:
N/a

Reusable State(s):
N/a

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours>
firmware.location <Configured invalid firmware
location>
firmware.retrieveDateTime <Current DateTime +
<Current DateTime - 2 hours>>
firmware.signingCertificate <Configured invalid
firmware signingCertificate>
firmware.signature <Configured invalid firmware
signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station notifies the CSMS about the
current state of all connectors. 10. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may
wants to set its connectors to Unavailable, before
proceeding installing the new firmware.

11. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
12. The Charging Station sends a
FirmwareStatusNotificationRequest 13. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did NOT reboot before firmware installation, at
step 11.

OCPP 2.0.1 - © Open Charge Alliance 2024 122/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - InstallVerificationFailed or InstallationFailed
Note: Step 14 through 17 can be send in a different order.
14. The Charging Station notifies the CSMS about
the current state of all connectors. 15. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
9) and the Charging Station did not report setting
them back to Available (after the reboot sequence at
step 11) yet.
- And if the Charging Station did not become
inoperative after the firmware update failure. It is
recommended for a Charging Station to fallback to
the previous firmware after a firmware update failure.
16. The Charging Station sends a
FirmwareStatusNotificationRequest 17. The OCTT responds with a
With status InstallVerificationFailed or FirmwareStatusNotificationResponse
InstallationFailed

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 12:
Message FirmwareStatusNotificationRequest
- status Installing
* Step 14:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 16:
Message FirmwareStatusNotificationRequest
- status InstallVerificationFailed or InstallationFailed

OCPP 2.0.1 - © Open Charge Alliance 2024 123/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - InstallVerificationFailed or InstallationFailed

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 124/145 Edition 2 - Errata 2024-04
Table 22. Test Case Id: TC_L_14_CS
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true
Test case Id TC_L_14_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install/activate a new firmware
by sending an UpdateFirmwareRequest with a signingCertificate. When the Installing phase is not possible
while a transaction is ongoing, Charging Station will report InstallScheduled and wait for transction(s) to
finish first, else it will immediately report Installing. In both cases before activation of new firmware by
(optional) reboot and a reconnect, Charging Station will always wait for transaction(s) to finish.
Purpose To verify if the Charging Station is able to keep allowing new transactions when requested to update the
firmware, while there is an ongoing transaction.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The Charging Station is able to start more than one transaction at a time.
- The Charging Station is unable to install and/or activate firmware while there is an ongoing transaction.

Before Configuration State:

(Preparations) AllowNewSessionsPendingFirmwareUpdate is true (If implemented)

Memory State:
N/a

Reusable State(s):
State is EnergyTransferStarted for EVSEId 1 and ConnectorId 1

OCPP 2.0.1 - © Open Charge Alliance 2024 125/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest
With status InstallScheduled or status Installing
10. The OCTT responds with a
Note(s): FirmwareStatusNotificationResponse
- InstallScheduled only applies when Charging Station
is not able to install while a transaction is active.

11. Execute Reusable State EnergyTransferStarted for <Configured second Connector>

Note(s):
- It is allowed to start a second transaction while there is a (scheduled) firmware update.
11a. If Charging Station reported Installing in step 9 then wait a while (30-60 s) before continuing with next
steps to stop transactions to allow time to install firmware.

12. Execute Reusable State ParkingBayUnoccupied for <Configured connectorId>

Note(s):
- The Charging Station will proceed to this end state. This will cause the first transaction to stop.

13. Execute Reusable State ParkingBayUnoccupied for <Configured second Connector>

Note(s):
- The Charging Station will proceed to this end state. This will cause the second transaction to stop.
- The Charging Station will start the firmware update process (if it had not started installing in step 9) the
moment this second transaction ends or when all interactions with the EV Driver are done (so after the cable
has been unplugged, assuming there is no parking bay sensor).
14. The Charging Station notifies the CSMS about
the current state of all connectors. 15. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may want
to set its connectors to Unavailable, before
proceeding installing the new firmware.

OCPP 2.0.1 - © Open Charge Alliance 2024 126/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

16. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
17. The Charging Station sends a
FirmwareStatusNotificationRequest 18. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did not report Installing at step 9 and did not
reboot before firmware installation, at step 16
(because that step already reports Installing).

19. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

20. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 21 through 26 can be sent in a different order.
21. The Charging Station notifies the CSMS about
the current state of all connectors. 22. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
14) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 16 or 19) yet.
23. The Charging Station sends a
FirmwareStatusNotificationRequest 24. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
25. The Charging Station sends a
SecurityEventNotificationRequest 26. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 127/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message FirmwareStatusNotificationRequest
- status InstallScheduled or Installing
* Step 14: (optional)
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 17: (optional depending on step 9)
Message FirmwareStatusNotificationRequest
- status Installing
* Step 21:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 23:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 25:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 128/145 Edition 2 - Errata 2024-04
Table 23. Test Case Id: TC_L_15_CS
Test case name Secure Firmware Update - Unable to install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false
Test case Id TC_L_15_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate. When the Installing phase is not possible
while a transaction is ongoing, Charging Station will report InstallScheduled and wait for transction(s) to
finish first, else it will immediately report Installing. In both cases before activation of new firmware by
(optional) reboot and a reconnect, Charging Station will always wait for transaction(s) to finish.
Purpose To verify if the Charging Station is able to set its available connectors to Unavailable when requested to
update the firmware, while there is an ongoing transaction.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The configuration variable AllowNewSessionsPendingFirmwareUpdate is implemented.
- The Charging Station is unable to install firmware while there is an ongoing transaction.

Before Configuration State:

(Preparations) AllowNewSessionsPendingFirmwareUpdate is false

Memory State:
N/a

Reusable State(s):
State is EnergyTransferStarted

OCPP 2.0.1 - © Open Charge Alliance 2024 129/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest 10. The OCTT responds with a
With status InstallScheduled or status Installing FirmwareStatusNotificationResponse

Note: InstallScheduled only applies when Charging

Station is not able to install while a transaction is
active. Part 2 specification only describes that this
status needs to be send in case the installDateTime is
in the future. However, it is also allowed to send this
status if the Charging Station schedules the firmware
installation, because of an ongoing transaction.
11. The Charging Station notifies the CSMS that its
Available connector(s) have been set to Unavailable. 12. The OCTT responds accordingly.

Note(s):
- This step needs to be executed for all connectors
with AvailabilityState Available.
12a. If Charging Station reported Installing in step 9 then wait a while (30-60 s) before continuing with next
steps to stop transaction to allow time to install firmware.

13. Execute Reusable State ParkingBayUnoccupied for <Configured connectorId>

Note(s):
- The Charging Station will proceed to this end state. This will cause the transaction to stop.
- The Charging Station will start the firmware update process (if it had not started installing in step 9) the
moment the transaction ends or when all interactions with the EV Driver are done (so after the cable has been
unplugged, assuming there is no parking bay sensor).
14. The Charging Station notifies the CSMS about
the current state of all connectors. 15. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may want
to set its last connector to Unavailable, before
proceeding installing the new firmware.

OCPP 2.0.1 - © Open Charge Alliance 2024 130/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

16. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
17. The Charging Station sends a
FirmwareStatusNotificationRequest 18. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did not report Installing at step 9 and did not
reboot before firmware installation, at step 16
(because that step already reports Installing).

19. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

20. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 21 through 26 can be sent in a different order.
21. The Charging Station notifies the CSMS about
the current state of all connectors. 22. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
14) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 16 or 19) yet.
23. The Charging Station sends a
FirmwareStatusNotificationRequest 24. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
25. The Charging Station sends a
SecurityEventNotificationRequest 26. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 131/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message FirmwareStatusNotificationRequest
- status InstallScheduled or Installing
* Step 11:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 14: (optional)
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 17: (optional depending on step 9)
Message FirmwareStatusNotificationRequest
- status Installing
* Step 21:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 23:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 25:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 132/145 Edition 2 - Errata 2024-04
6.1.36. Page 259 - (2024-04) - TC_L_14_CS - Updated to support A/B firmware
updates
This test case now supports installation (but not activation) of firmware while a transaction is active.

Table 24. Test Case Id: TC_L_14_CS

Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true
Test case Id TC_L_14_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install/activate a new firmware
by sending an UpdateFirmwareRequest with a signingCertificate. When the Installing phase is not possible
while a transaction is ongoing, Charging Station will report InstallScheduled and wait for transction(s) to
finish first, else it will immediately report Installing . In both cases before activation of new firmware by
(optional) reboot and a reconnect, Charging Station will always wait for transaction(s) to finish.
Purpose To verify if the Charging Station is able to keep allowing new transactions when requested to update the
firmware, while there is an ongoing transaction.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The Charging Station is able to start more than one transaction at a time.
- The Charging Station is unable to install and/or activate firmware while there is an ongoing transaction.

Before Configuration State:

(Preparations) AllowNewSessionsPendingFirmwareUpdate is true (If implemented)

Memory State:
N/a

Reusable State(s):
State is EnergyTransferStarted for EVSEId 1 and ConnectorId 1

OCPP 2.0.1 - © Open Charge Alliance 2024 133/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest
With status InstallScheduled or status Installing
10. The OCTT responds with a
Note(s): FirmwareStatusNotificationResponse
- InstallScheduled only applies when Charging Station
is not able to install while a transaction is active.

11. Execute Reusable State EnergyTransferStarted for <Configured second Connector>

Note(s):
- It is allowed to start a second transaction while there is a (scheduled) firmware update.
11a. If Charging Station reported Installing in step 9 then wait a while (30-60 s) before continuing with next
steps to stop transactions to allow time to install firmware.

12. Execute Reusable State ParkingBayUnoccupied for <Configured connectorId>

Note(s):
- The Charging Station will proceed to this end state. This will cause the first transaction to stop.

13. Execute Reusable State ParkingBayUnoccupied for <Configured second Connector>

Note(s):
- The Charging Station will proceed to this end state. This will cause the second transaction to stop.
- The Charging Station will start the firmware update process (if it had not started installing in step 9) the
moment this second transaction ends or when all interactions with the EV Driver are done (so after the cable
has been unplugged, assuming there is no parking bay sensor).
14. The Charging Station notifies the CSMS about
the current state of all connectors. 15. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may want
to set its connectors to Unavailable, before
proceeding installing the new firmware.

OCPP 2.0.1 - © Open Charge Alliance 2024 134/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

16. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
17. The Charging Station sends a
FirmwareStatusNotificationRequest 18. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did not report Installing at step 9 and did not
reboot before firmware installation , at step 16
(because that step already reports Installing ) .

19. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

20. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 21 through 26 can be sent in a different order.
21. The Charging Station notifies the CSMS about
the current state of all connectors. 22. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
14) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 16 or 19) yet.
23. The Charging Station sends a
FirmwareStatusNotificationRequest 24. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
25. The Charging Station sends a
SecurityEventNotificationRequest 26. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 135/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is true

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message FirmwareStatusNotificationRequest
- status InstallScheduled or Installing
* Step 14: (optional)
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 17: (optional depending on step 9)
Message FirmwareStatusNotificationRequest
- status Installing
* Step 21:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 23:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 25:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 136/145 Edition 2 - Errata 2024-04
6.1.37. Page 262 - (2024-04) - TC_L_15_CS - Updated to support A/B firmware
updates
This test case now supports installation (but not activation) of firmware while a transaction is active.

Table 25. Test Case Id: TC_L_15_CS

Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false
Test case Id TC_L_15_CS
Use case Id(s) L01
Requirement(s) L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20
System under test Charging Station
Description The CSMS is able to request the Charging Station to securely download and install a new firmware by
sending an UpdateFirmwareRequest with a signingCertificate. When the Installing phase is not possible
while a transaction is ongoing, Charging Station will report InstallScheduled and wait for transction(s) to
finish first, else it will immediately report Installing . In both cases before activation of new firmware by
(optional) reboot and a reconnect, Charging Station will always wait for transaction(s) to finish.
Purpose To verify if the Charging Station is able to set its available connectors to Unavailable when requested to
update the firmware, while there is an ongoing transaction.
Prerequisite(s) - A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s),
indicated by the configuration variable FileTransferProtocols.
- The configuration variable AllowNewSessionsPendingFirmwareUpdate is implemented.
- The Charging Station is unable to install and/or activate firmware while there is an ongoing transaction.

Before Configuration State:

(Preparations) AllowNewSessionsPendingFirmwareUpdate is false

Memory State:
N/a

Reusable State(s):
State is EnergyTransferStarted

OCPP 2.0.1 - © Open Charge Alliance 2024 137/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

Main Charging Station CSMS

(Test scenario) 1. The OCTT sends a UpdateFirmwareRequest
2. The Charging Station responds with a with firmware.installDateTime <Current DateTime - 2
UpdateFirmwareResponse hours> firmware.location <Configured
With status Accepted firmware_location>
firmware.retrieveDateTime <Current DateTime - 2
hours>
firmware.signingCertificate <Configured
signingCertificate>
firmware.signature <Configured signature>
3. The Charging Station sends a
FirmwareStatusNotificationRequest 4. The OCTT responds with a
With status Downloading FirmwareStatusNotificationResponse
5. The Charging Station sends a
FirmwareStatusNotificationRequest 6. The OCTT responds with a
With status Downloaded FirmwareStatusNotificationResponse
7. The Charging Station sends a
FirmwareStatusNotificationRequest 8. The OCTT responds with a
With status SignatureVerified FirmwareStatusNotificationResponse
9. The Charging Station sends a
FirmwareStatusNotificationRequest 10. The OCTT responds with a
With status InstallScheduled or status Installing FirmwareStatusNotificationResponse

Note: InstallScheduled only applies when Charging

Station is not able to install while a transaction is
active. Part 2 specification only describes that this
status needs to be send in case the installDateTime is
in the future. However, it is also allowed to send this
status if the Charging Station schedules the firmware
installation, because of an ongoing transaction.
11. The Charging Station notifies the CSMS that its
Available connector(s) have been set to Unavailable. 12. The OCTT responds accordingly.

Note(s):
- This step needs to be executed for all connectors
with AvailabilityState Available.
12a. If Charging Station reported Installing in step 9 then wait a while (30-60 s) before continuing with next
steps to stop transaction to allow time to install firmware.

13. Execute Reusable State ParkingBayUnoccupied for <Configured connectorId>

Note(s):
- The Charging Station will proceed to this end state. This will cause the transaction to stop.
- The Charging Station will start the firmware update process (if it had not started installing in step 9) the
moment the transaction ends or when all interactions with the EV Driver are done (so after the cable has been
unplugged, assuming there is no parking bay sensor).
14. The Charging Station notifies the CSMS about
the current state of all connectors. 15. The OCTT responds accordingly.

Note(s):
- This step is optional. The Charging Station may want
to set its last connector to Unavailable, before
proceeding installing the new firmware.

OCPP 2.0.1 - © Open Charge Alliance 2024 138/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

16. Execute Reusable State RebootBeforeFirmwareInstallation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware
installation.
17. The Charging Station sends a
FirmwareStatusNotificationRequest 18. The OCTT responds with a
With status Installing FirmwareStatusNotificationResponse

Note(s):
- This step only needs to be executed if the Charging
Station did not report Installing at step 9 and did not
reboot before firmware installation, at step 16
(because that step already reports Installing).

19. Execute Reusable State RebootBeforeFirmwareActivation

Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.

20. The OCTT waits for the Charging Station to reconnect.

Note: This step only needs to be executed if the Charging Station did not reboot/reconnect up until this point.
The Charging Station should at least reconnect to reestablish the protocol version handshake.
Note: Step 21 through 26 can be sent in a different order.
21. The Charging Station notifies the CSMS about
the current state of all connectors. 22. The OCTT responds accordingly.

Note(s):
- This step only needs to be executed if the
connectors were previously set to Unavailable (at step
14) and the Charging Station did not report setting
them back to Available (after a reboot sequence at
step 16 or 19) yet.
23. The Charging Station sends a
FirmwareStatusNotificationRequest 24. The OCTT responds with a
With status Installed FirmwareStatusNotificationResponse
25. The Charging Station sends a
SecurityEventNotificationRequest 26. The OCTT responds with a
With type FirmwareUpdated SecurityEventNotificationResponse

OCPP 2.0.1 - © Open Charge Alliance 2024 139/145 Edition 2 - Errata 2024-04
Test case name Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -
AllowNewSessionsPendingFirmwareUpdate is false

Tool validations * Step 2:

Message UpdateFirmwareResponse
- status Accepted
* Step 3:
Message FirmwareStatusNotificationRequest
- status Downloading
* Step 5:
Message FirmwareStatusNotificationRequest
- status Downloaded
* Step 7:
Message FirmwareStatusNotificationRequest
- status SignatureVerified
* Step 9:
Message FirmwareStatusNotificationRequest
- status InstallScheduled or Installing
* Step 11:
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 14: (optional)
Message: StatusNotificationRequest
- connectorStatus Unavailable
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Unavailable"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 17: (optional depending on step 9)
Message FirmwareStatusNotificationRequest
- status Installing
* Step 21:
Message: StatusNotificationRequest
- connectorStatus Available
Or
Message: NotifyEventRequest
- eventData[0].trigger Delta
- eventData[0].actualValue "Available"
- eventData[0].component.name "Connector"
- eventData[0].variable.name "AvailabilityState"
* Step 23:
Message FirmwareStatusNotificationRequest
- status Installed
* Step 25:
Message SecurityEventNotificationRequest
- type FirmwareUpdated

Post scenario validations:

N/a

OCPP 2.0.1 - © Open Charge Alliance 2024 140/145 Edition 2 - Errata 2024-04
6.1.38. Page 268 - (2024-04) - TC_M_01_CS - Incorrect note about
AdditionalRootCertificateCheck and new CSMSRoot needs to be installed
The first configured CSMSRoot is already installed while using security profile 2 or 3. So this testcase needs to install a new
CSMSRoot certificate to validate if a Charging Station is able to install a new Root certificate.

Changed main steps

Old text 1. Execute Reusable State CertificateInstalled for certificateType CSMSRootCertificate

Note(s):
- When the Charging Station has the following configuration; AdditionalRootCertificateCheck implemented with
value true, then a custom CSMSRootCertificate should be used.
- When the Charging Station has the following configuration; AdditionalRootCertificateCheck implemented with
value false, then the the built-in action to delete the newly installed certificate should be executed.
New text 1. Execute Reusable State CertificateInstalled for certificateType CSMSRootCertificate (Root 2)

Note(s):
- When the Charging Station has the following configuration; AdditionalRootCertificateCheck implemented with
value true, then a custom CSMSRootCertificate should be used.
- When the Charging Station has the following configuration; AdditionalRootCertificateCheck implemented with
value false, then the the built-in action to delete the newly installed certificate should be executed.

6.1.39. Page 268-281 - (2023-12) - TC_M_XX_CS - Testcases only applicable when

security profile 2 or 3 is supported
These testcases are only applicable for Charging Stations that support either security profile 2 or 3. However for a Charging Station
that supports only security profile 1, part 2 specification describes the following:

• The Unsecured Transport with Basic Authentication Profile does not include authentication for the CSMS, or
measures to set up a secure communication channel. Therefore, it should only be used in trusted networks, for
instance in networks where there is a VPN between the CSMS and the Charging Station. For field operation it is highly
recommended to use a security profile with TLS.
• In some cases (e.g. lab installations, test setups, etc.) one might prefer to use OCPP 2.0.1 without implementing
security. While this is possible, it is NOT considered a valid OCPP 2.0.1 implementation.

Therefore these testcases is mandatory to pass for certification.

Added Prerequisite(s) - The Charging Station supports Security Profile 2 or 3.

6.1.40. Page 269/276 - (2023-12) - TC_M_02_CS & TC_M_13_CS & TC_M_17_CS &
TC_M_18_CS - Only applicable when signed firmware update is supported
This testcase is only applicable for Charging Stations that support signed firmware updates. However it is highly recommended to
support the signed variant, opposed to the unsigned firmware update variant. For certification only the implementation of the
signed firmware update is allowed, so therefore this testcase is mandatory for certification.

Additionally the existing prerequisite from TC_M_02_CS is removed, because the variable AdditionalRootCertificateCheck does not
effect the ManufacturerRootCertificate.

Old text Prerequisite(s) The Charging Station does NOT have the following configuration;
AdditionalRootCertificateCheck is implemented with value true
New text Prerequisite(s) - The Charging Station supports signed firmware updates.

OCPP 2.0.1 - © Open Charge Alliance 2024 141/145 Edition 2 - Errata 2024-04
6.1.41. Page 279 - (2024-04) - TC_M_19_CS - Removing MORootCertifiate in
preparation phase when needed
Old Configuration State:
text N/a
New Configuration State:
text OCTT checks to make sure that no MORootCertificate is installed via GetInstalledCertificateIds. If an MORootCertificate
exists it removes it via DeleteCertificate.

6.1.42. Page 282 - (2023-12) - TC_M_23_CS - Testcase only applicable when

security profile 3 is supported
This testcase is only applicable for Charging Stations that support security profile 3.

Old text Prerequisite(s) N/a

New text Prerequisite(s) - The Charging Station supports Security Profile 3.
- A valid CSMSRootCertificate is installed on the Charging Station.

6.1.43. Page 284 - (2023-12) - TC_N_26_CS - Require a minimal size for the
configured retry interval, based on the upload speed
The OCTT can is very flexible in its configurations, however some testcases prevent certain configured value combinations or
require a minimal size, depending on the speed of the system. This is to prevent false positives or negatives.

Changed preparations

Old text Configuration State: N/a

New text Configuration State: The retry interval should be configured longer than the time it takes to attempt an
upload.

Additionally an issue has been fixed regarding tool validation step numbering and the amount of times the OCTT expects the
Charging Station to repeat step(s) (3) 5.

Changed note main step

Old text Note(s):

- Steps 3 & 4 are optional after the first attempt.
- The Charging Station will perform step (3,) 5, three times with <Configured retryInterval> seconds in between.
New text Note(s):
- Steps 3 & 4 are optional after the first attempt.
- The Charging Station will perform step (3,) 5, four times with <Configured retryInterval> seconds in between.

Changed tool validation step

Old text * Step 1:

Message GetLogResponse
- status Accepted
New text * Step 2 :
Message GetLogResponse
- status Accepted

6.1.44. Page 293 - (2023-12) - TC_N_36_CS - Missing prerequisite

This testcase is only applicable for Charging Station that support cancelling an ongoing log file upload.

Added Prerequisite(s) The Charging Station supports cancelling an ongoing log file upload.

OCPP 2.0.1 - © Open Charge Alliance 2024 142/145 Edition 2 - Errata 2024-04
6.1.45. Page 292/293 - (2023-12) - TC_N_35_CS & TC_N_36_CS - Invalid
prerequisite
Log file upload is part of functional block N, but is not related to monitoring.

Removed Prerequisite(s) Charging Station supports Monitoring

6.1.46. Page 308 - (2023-12) - Reusable State: EnergyTransferSuspended -

Increased flexibility to support Charging Stations with high level communication
In case of high level communication, the transaction might already be not authorized anymore. Therefore the
EnergyTransferSuspended reusable state has been made more flexible in its validations.

Changed tool validation step

Old text * Step 1:

Message: TransactionEventRequest
- triggerReason must be ChargingStateChanged
- transactionInfo.chargingState must be EVConnected OR
- transactionInfo.chargingState must be SuspendedEV AND
- transactionInfo.stoppedReason must be StoppedByEV
- eventType must be Ended OR Updated
New text * Step 1:
Message: TransactionEventRequest
- triggerReason must be ChargingStateChanged (If chargingState = SuspendedEV )
- transactionInfo.chargingState must be EVConnected OR SuspendedEV
- transactionInfo.stoppedReason must be StoppedByEV (if eventType = Ended )
- eventType must be Ended OR Updated

OCPP 2.0.1 - © Open Charge Alliance 2024 143/145 Edition 2 - Errata 2024-04
6.2. Test Cases Charging Station Management System

6.2.1. Page 380 - (2023-12) - TC_E_39_CSMS - Missing requirement reference

Added applicable requirement reference.

Old text Requirement(s) E03.FR.05, E06.FR.04

New text Requirement(s) E03.FR.04, E03.FR.05, E06.FR.04

6.2.2. Page 384 - (2023-12) - TC_E_21_CSMS - Missing requirement reference

Added applicable requirement reference.

Old text Requirement(s) E06.FR.03,F03.FR.01,F03.FR.09

New text Requirement(s) E06.FR.03,F03.FR.01,F03.FR.09 , F03.FR.10

6.2.3. Page 400 - (2023-12) - TC_E_31_CSMS - Added missing StatusNotification

steps
To correctly simulate the scenario, the OCTT needs to send StatusNotificationRequest(s).

Added main steps

Added 3. The OCTT sends a StatusNotificationRequest

With evseId is <Configured evseId>
connectorId is <Configured connectorId>
connectorStatus is Available
4. The CSMS responds with a StatusNotificationResponse

6.2.4. Page 407 - (2023-12) - TC_F_04_CSMS - Missing requirement reference

Added applicable requirement reference.

Old text Requirement(s) E03.FR.05

New text Requirement(s) E03.FR.04, E03.FR.05

6.2.5. Page 447 - (2023-12) - TC_L_05_CSMS - Added missing

SecurityEventNotification steps
To correctly simulate the scenario, the OCTT needs to send a SecurityEventNotificationRequest.

Added main steps

Added 3. The OCTT sends a SecurityEventNotificationRequest

With type is InvalidFirmwareSigningCertificate
4. The CSMS responds with a SecurityEventNotificationResponse

6.2.6. Page 448 - (2023-12) - TC_L_06_CSMS - Added missing

SecurityEventNotification steps
To correctly simulate the scenario, the OCTT needs to send a SecurityEventNotificationRequest.

Added main steps

OCPP 2.0.1 - © Open Charge Alliance 2024 144/145 Edition 2 - Errata 2024-04
Added 9. The OCTT sends a SecurityEventNotificationRequest
With type is InvalidFirmwareSignature
10. The CSMS responds with a SecurityEventNotificationResponse

6.2.7. Page 473 - (2023-12) - TC_E_32_CSMS - Added missing

NotifyCustomerInformation steps
To correctly simulate the scenario, the OCTT needs to send a NotifyCustomerInformationRequest.

Added main steps

Added 3. The OCTT sends a NotifyCustomerInformationRequest

4. The CSMS responds with a NotifyCustomerInformationResponse

6.2.8. Page General - (2024-04) - Added testcase list for the other certification
profiles
At edition 3 of the specification all testcases for the other certification profiles are included.
The included certification profiles;

• Local Authorization List Management (D. Local Authorization List Management)

• Smart Charging (K. SmartCharging)
• Advanced Device Management (B. Provisioning & N. Diagnostics)
• Reservation (H. Reservation)
• Advanced User Interface (I. Tariff & Cost & O. Display Message)
• ISO 15118 Support

OCPP 2.0.1 - © Open Charge Alliance 2024 145/145 Edition 2 - Errata 2024-04